ASF JIRA

Commons Collections

COLLECTIONS-71

Missing LICENSE in source distribution (commons-collections-1.0-src.tar.gz)

Bug

Closed

Blocker

Fixed

Unassigned

Michael Marrotte

05/Mar/02 02:11

18/Mar/20 03:01

15/Mar/08 21:36

1.0

0

Operating System: Linux
Platform: Other

The build.xml in "commons-collections-1.0-src.tar.gz", references the
"LICENSE" file that does not exist.

This blocks a successful build of the API docs, i.e. "ant doc" as in
"README.TXT".

I "touched ../../LICENSE" for a quick fix.

--MTM

10/Apr/02 10:33 AM

17 years, 51 weeks, 6 days ago

18927

No Perforce job exists for this issue.

0

6855

164637

0|i0sji7:

Commons Collections

COLLECTIONS-23

BeanMap.putAll(beanmap) fails

Bug

Closed

Minor

Fixed

Unassigned

Joe Shelby

30/Jul/02 03:08

18/Mar/20 02:52

15/Mar/08 21:35

2.0

0

Operating System: other
Platform: Other

I created two beanmaps, both around objects of the same class, to try to
effectively clone the underlying objects (this was before I looked harder and
realized that BeanMap.clone() would try to instantiate a new object on its own).

I found that this fails with a java.lang.IllegalArgumentException: The bean of
type: com.isx.isaf.IsafAgentDescription has no property called: class

The reason: BeanMap's underlying introspector notices the read-only property of
"class" (the class of the bean object), and has a get() entry for it that has
no matching put.

When AbstractMap.putAll iterates through the values, it tries to put() the class
value and this causes the failure.

The workarounds is to reimplement putAll() outside the map and catch exceptions
for every failed put (this should be the only one unless the bean itself has
other read-only properties).

BeanMap.clone() correctly checks for read-only properties and doesn't try to
set them, but is limited to beans that have zero-parameter constructors; its
real problem is that it is still "protected" in BeanMap, not public.

Possible fix is to override putAll() from AbstractMap and check if the
property is read-only before calling put() and ignoring it if it is. Options
involving fixing put() itself would cause more problems than solutions, IMHO.

Another fix is to catch the "class" property and filter it out completely so
it never shows up in the keySet or entrySet at all.

10/Aug/02 9:06 AM

17 years, 34 weeks, 3 days ago

18975

No Perforce job exists for this issue.

0

11262

164685

0|i0sjsv:

Commons Collections

COLLECTIONS-28

SequencedHashMap.indexOf(Object key) throws annoying exceptions

Bug

Closed

Major

Fixed

Unassigned

Johal

18/Oct/02 16:10

18/Mar/20 02:50

15/Mar/08 21:35

2.0

0

Operating System: All
Platform: All

Is it intentional that SequencedHashMap.indexOf(Object key) throws a
NullPointerException when the key does not exist in the map?

Shouldn't it return -1 in those situations?

Here is an addition to the TestSequencedHashMap which examplifies the problem

public void testIndexOf() throws Exception {
Object[] keys = getKeys();
int expectedSize = keys.length;
Object[] values = getValues();
for (int i = 0; i < expectedSize; i++) {
labRat.put(keys[i], values[i]);
}
// test that the index returned are in the same order that they were
// placed in the map
for (int i=0;i<keys.length;i++) {
assertEquals("indexOf with existing key failed",i,labRat.indexOf(keys[i]));
}
// test non existing key..

assertEquals("test with non-existing key failed",-1,labRat.indexOf
("NonExistingKey"));
}

25/Nov/02 4:51 AM

17 years, 19 weeks, 1 day ago

18970

No Perforce job exists for this issue.

0

13758

164680

0|i0sjrr:

Commons Collections

COLLECTIONS-86

LRUMap.get doesn't change usage status

Bug

Closed

Major

Fixed

Unassigned

Frank Finger

17/Oct/02 14:48

18/Mar/20 02:50

15/Mar/08 21:36

2.0

0

Operating System: All
Platform: PC

LRUMap drops the least resently added item, not the least recently used one. The
following test fails in line 6 (and 7, if you comment out 6).

1: LRUMap map = new LRUMap( 2 );
2: map.put( "2", "zwei" );
3: map.put( "3", "drei" );

4: map.get( "2" ); // now, "2" should be least recently used
5: map.put( "4", "vier" ); // this should drop "3"

6: assertEquals( "zwei", map.get("2") );
7: assertEquals( null, map.get("3") );
8: assertEquals( "vier", map.get("4") );

17/Oct/02 7:41 PM

17 years, 24 weeks, 5 days ago

18912

No Perforce job exists for this issue.

0

13722

164622

0|i0sjev:

Commons Collections

COLLECTIONS-103

SoftRefHashMap is all kinds of wonky

Bug

Closed

Major

Fixed

Unassigned

Paul Jack

03/Jun/02 13:12

18/Mar/20 02:51

14/Jul/06 05:45

14/Jul/06 05:33

2.0

2.1

1

0

Operating System: All
Platform: All

Many methods in SoftRefHashMap do not conform the the java.util.Map
specification. After you populate a SoftRefHashMap using its put or putAll
method, it transforms the values into SoftReferences. The get() method
correctly re-translates the SoftReferences back into the actual object values,
unless they've been garbage collected.

However, the entrySet() collection view does NOT perform this reverse
translation; iterating over an entry set gives you Map.Entry with SoftReference
values. Since the equals() and hashCode() methods rely on iterating over the
entry set, equals() and hashCode() are broken in SoftRefHashMap.

Also, it's odd that after I put(key,value), containsValue(value) will return
true, yet I won't be able to find the value in the entry set.

Also, invoking setValue() on a Map.Entry in the entrySet will correctly update
the map with a new value; however, the old value is not returned as per the Map
specification.

Also, the values() and entrySet() collection views are not backed by the map;
alterations to the map are not reflected in any existing values() or entrySet()
collection views.

Also, containsKey(Object) is wierd. If I put(key,value), and the value is
subsequently garbage collected, containsValue(value) will return false, yet
containsKey(key) will still return true.

Creating a values() collection view creates hard references to the map's
values, essentially ruining the point of the class (so long as the values()
collection view exists, the map does not function as a memory-aware cache).

Finally, iterating over keySet() and entrySet() is wonky. Mappings might have
been removed by the garbage collector, but the iterators will still return an
object for the mapping. So keySet()'s iterator will return keys for values
that aren't there anymore, and entrySet()'s iterator will return Map.Entries
with keys that map to null instead of values.

17 years, 34 weeks, 1 day ago

18895

No Perforce job exists for this issue.

0

9571

164605

0|i0sjb3:

Commons Collections

COLLECTIONS-385

Inconsistent Javadoc comment and code in addAll(Collection, Object[]) in org.apache.commons.collections.CollectionUtils

Bug

Closed

Major

Not A Problem

Unassigned

SHIN HWEI TAN

26/Oct/11 20:27

18/Mar/20 02:54

27/Nov/15 21:47

26/Jul/12 21:06

2.1, 2.1.1, 3.0, 3.1, 3.2

Collection

0

300

0%

Platform Independent

The Javadoc comment below states that the method "throws NullPointerException if the collection or array is null".
/**
* Adds all elements in the array to the given collection.
*
* @param collection the collection to add to, must not be null
* @param elements the array of elements to add, must not be null
* @throws NullPointerException if the collection or array is null
*/
public static void addAll(Collection collection, Object[] elements) {
for (int i = 0, size = elements.length; i < size; i++) {
collection.add(elements[i]);
}
}

However, when called with an empty array and a null collection (i.e., "addAll((Collection)null, new Object[])"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if the collection or array is null" from the Javadoc.
or
3. Change "@throws NullPointerException if the collection or array is null" to "@throws NullPointerException if the array is null or (the array is non-empty and the collection is null)".

0%

300

javadoc, nullpointerexception

29/Oct/11 9:11 PM

8 years, 21 weeks, 3 days ago

214816

No Perforce job exists for this issue.

0

164370

0|i0shuv:

Commons Collections

COLLECTIONS-6

[Collections] - MapUtils]Method to generate a Map from a Object[][]

Bug

Closed

Major

Fixed

Unassigned

Rafael U. C. Afonso

27/Aug/04 08:02

18/Mar/20 02:51

15/Mar/08 21:35

2.1

0

Operating System: other
Platform: Other

In Python Language it is possible create a dictionary (equivalent to Map) using
only a single line:

myMap = {'alpha':'a', 'betha':'b', 'gamma':'c'}

In Java it is not possible. We must do it "manually":

Map myMap = new HashMap();
myMap.put("alpha", "a");
myMap.put("betha", "b");
myMap.put("gamma", "c");

My propose is create a way to do this with less burocracy. In
org.apache.commons.collections.MapUtils class could have a method called
fillMap (or better name) that receives a Map and a bi-dimentional array of
Objects. It will work like this:

public static Map fillMap(Map map, Object[][] keyValue) {
for(int i = 0; i < keyValue.length; i ++) {
map.put(keyValue[i][0], keyValue[i][1]);
}
return map;
}

So, returning to prior example, we could do this:

Map myMap = MapUtils.fillMap(new HashMap(), {{"alpha", "a"}, {"betha", "b"},
{"gama", "c"}});

Or to put in mass in a pre-existent MAP:

MapUtils.fillMap(myMap, {{"delta", "d"}, {"epslon", "e"}, {"omega", "z"}});

23/Sep/04 6:06 AM

15 years, 27 weeks, 5 days ago

18992

No Perforce job exists for this issue.

1

30882

164702

0|i0sjwn:

Commons Collections

COLLECTIONS-55

[collections] Filling out PredicatedXXX Javadoc - a functor package.html

Bug

Closed

Major

Fixed

Unassigned

Tim O'Brien

16/May/04 09:30

18/Mar/20 02:51

15/Mar/08 21:35

2.1

0

Operating System: other
Platform: Other

In general Predicated collections and maps should probably be created before a
data structure has any contents. Maybe this is just an artifact of the way I
use PredicatedList, but, nevertheless, I think all of the PredicatedXXX
classes need fuller JavaDoc - possibly pointing to an anchor in the
package.html for the functors package that talks about some scenarios for
using PredicatedXXX classes. Right now we don't have a good in JavaDoc
explanation of the various ways to apply a Predicate to a collection.

(I'm on a Javadoc kick, sorry.)

22/May/04 4:40 AM

15 years, 45 weeks, 3 days ago

18943

No Perforce job exists for this issue.

0

29018

164653

0|i0sjlr:

Commons Collections

COLLECTIONS-100

[collections] IteratorChain bug with empty iterators.

Bug

Closed

Major

Incomplete

Unassigned

Andrus Adamchik

03/Dec/03 13:11

18/Mar/20 02:51

15/Mar/08 21:36

2.1

0

Operating System: All
Platform: All

Haven't tried this with nightly builds, but 2.1 collections have the follwoing
problem: when the first iterator in a chain is empty, first call to "hasNext"
returns false, on second and subsequent calls, "true" is returned again as it
should. Here is an example:

List emptyList = new ArrayList();
List nonEmptyList = new ArrayList();
nonEmptyList.add(new Object());

IteratorChain it = new IteratorChain(new Iterator[]
{emptyList.iterator(), nonEmptyList.iterator()});
System.out.println("Next? " + it.hasNext()); // prints false
System.out.println("Next again? " + it.hasNext()); // prints true

Cheers,
Andrus

05/Dec/03 1:11 AM

16 years, 17 weeks, 4 days ago

18898

No Perforce job exists for this issue.

0

25154

164608

0|i0sjbr:

Commons Collections

COLLECTIONS-80

[Patch] [Collections] ExtendedProperties.interpolate does not do recursive substitution

Bug

Closed

Major

Fixed

Unassigned

hoschek

16/Dec/03 12:15

18/Mar/20 02:51

15/Mar/08 21:36

2.1

0

Operating System: other
Platform: Other

[Patch] [Collections] ExtendedProperties.interpolate does not do recursive
substitution in commons-collections-2.1, but it probably should, when used with
getString(...).

Example:

firefish.home=/tmp/firefish
database.dir=${firefish.home}/samples/cfengine
database.file=${database.dir}/db.xml

extendedProps.getString("database.file")

I found out that this can be fixed with the patch below, which is simply a copy
and paste from the CVS of org.apache.commons.configuration.AbstractConfiguration.

/**
* interpolate key names to handle ${key} stuff
*
* @param base string to interpolate
*
* @return returns the key name with the ${key} substituted
*/
protected String interpolate(String base)
// copied from org.apache.commons.configuration.AbstractConfiguration
{
return (interpolateHelper(base, null));
}

/**
* Recursive handler for multple levels of interpolation.
*
* When called the first time, priorVariables should be null.
*
* @param base string with the ${key} variables
* @param priorVariables serves two purposes: to allow checking for
* loops, and creating a meaningful exception message should a loop
* occur. It's 0'th element will be set to the value of base from
* the first call. All subsequent interpolated variables are added
* afterward.
*
* @return the string with the interpolation taken care of
*/
protected String interpolateHelper(String base, List priorVariables)
// copied from org.apache.commons.configuration.AbstractConfiguration
{
if (base == null)
{
return null;
}

// on the first call initialize priorVariables
// and add base as the first element
if (priorVariables == null)
{
priorVariables = new ArrayList();
priorVariables.add(base);
}

int begin = -1;
int end = -1;
int prec = 0 - END_TOKEN.length();
String variable = null;
StringBuffer result = new StringBuffer();

// FIXME: we should probably allow the escaping of the start token
while (((begin = base.indexOf(START_TOKEN, prec + END_TOKEN.length()))
> -1)
&& ((end = base.indexOf(END_TOKEN, begin)) > -1))
{
result.append(base.substring(prec + END_TOKEN.length(), begin));
variable = base.substring(begin + START_TOKEN.length(), end);

// if we've got a loop, create a useful exception message and throw
if (priorVariables.contains(variable))
{
String initialBase = priorVariables.remove(0).toString();
priorVariables.add(variable);
StringBuffer priorVariableSb = new StringBuffer();

// create a nice trace of interpolated variables like so:
// var1->var2->var3
for (Iterator it = priorVariables.iterator(); it.hasNext();)
{
priorVariableSb.append(it.next());
if (it.hasNext())
{
priorVariableSb.append("->");
}
}

throw new IllegalStateException(
"infinite loop in property interpolation of "
+ initialBase
+ ": "
+ priorVariableSb.toString());
}
// otherwise, add this variable to the interpolation list.
else
{
priorVariables.add(variable);
}

//QUESTION: getProperty or getPropertyDirect
Object value = getProperty(variable);
if (value != null)
{
result.append(interpolateHelper(value.toString(),
priorVariables));

// pop the interpolated variable off the stack
// this maintains priorVariables correctness for
// properties with multiple interpolations, e.g.
// prop.name=${some.other.prop1}/blahblah/${some.other.prop2}
priorVariables.remove(priorVariables.size() - 1);
}
else if (defaults != null && defaults.getString(variable,
null) != null)
{
result.append(defaults.getString(variable));
}
else
{
//variable not defined - so put it back in the value
result.append(START_TOKEN).append(variable).append(END_TOKEN);
}
prec = end;
}
result.append(base.substring(prec + END_TOKEN.length(), base.length()));

return result.toString();
}

30/Dec/03 2:19 AM

16 years, 14 weeks, 1 day ago

18918

No Perforce job exists for this issue.

0

25553

164628

0|i0sjg7:

Commons Collections

COLLECTIONS-21

TestMap.tearDown() should throw Exception

Bug

Closed

Minor

Fixed

Unassigned

Rich Dougherty

01/Nov/02 07:20

18/Mar/20 02:51

15/Mar/08 21:35

2.1

0

Operating System: other
Platform: All

TestMap.tearDown() overrides TestCase.tearDown(). The original method throws an
Exception, however the redeclared method doesn't. This means that methods which
override TestMap.tearDown() cannot throw an Exception. In my case, I'm creating
and removing a test database in the setUp() and tearDown() so an Exception could
easily be thrown.

I realise that TestMap isn't part of Collections' public API, however I thought
I'd mention this in case other people want to reuse your excellent testing code.

02/Nov/02 3:09 AM

17 years, 22 weeks, 3 days ago

18977

No Perforce job exists for this issue.

0

14151

164687

0|i0sjtb:

Commons Collections

COLLECTIONS-128

[collections] IteratorChain - if first iterator empty, doesn't care about next ones.

Bug

Closed

Major

Fixed

Unassigned

Pawel Stawicki

10/Jan/04 21:27

18/Mar/20 02:51

15/Mar/08 21:36

14/Jul/06 12:04

2.1

1

0

Operating System: All
Platform: PC

If first Iterator in IteratorChain is empty, and next ones contain some
elements, first call to hasNext() on IteratorChain returns false. It should
return true if there are elements in other Iterators.

10/Jan/04 10:35 PM

13 years, 37 weeks, 4 days ago

18870

No Perforce job exists for this issue.

0

26038

164580

0|i0sj5j:

Commons Collections

COLLECTIONS-96

debug and verbose print in MapUtils only handles String keys

Bug

Closed

Major

Fixed

Unassigned

Matt Gould

14/Jan/04 10:22

18/Mar/20 02:51

15/Mar/08 21:36

2.1

0

Operating System: other
Platform: All

In MapUtils, if the key is e.g., Integer, fails with a ClassCastException:

for ( Iterator iter = map.entrySet().iterator(); iter.hasNext(); ) {
Map.Entry entry = (Map.Entry) iter.next();
==> String childKey = (String) entry.getKey();
Object childValue = entry.getValue();
if ( childValue instanceof Map ) {
verbosePrint( out, childKey, (Map) childValue );
}

Should not be cast to a String, just use Object, and it works.
Same thing goes for the less verbose sister method, debugPrint
Thanks,
Matt

15/Jan/04 4:52 AM

16 years, 11 weeks, 5 days ago

18902

No Perforce job exists for this issue.

0

26115

164612

0|i0sjcn:

Commons Collections

COLLECTIONS-50

[collections] ExtendedProperties combine and pre unescaped strings-values

Bug

Closed

Major

Won't Fix

Unassigned

Dean Arnold

20/Nov/03 17:42

18/Mar/20 02:51

15/Mar/08 21:35

2.1

0

Operating System: other
Platform: All

If you have 2 extended props (prop1 & prop2). prop1 contains some or none
key/value pairs and prop2 contains at least one key with string value with
commas that doesn't already exist in prop1. N.B. This assumes both props were
loaded from property files and the string values in prop2 were escaped in the
file-system properties.

If you call prop1.combine(prop2), the string-value from prop2 that contained
commas is treated as a non-escaped string and thus broken down into a Vector in
prop1. It should put the string-value into prop1 without procing the commas as
there were already processed by prop2 when it was loaded.

I believe that the combine method should merge the existing values from both
props and the putAll method should be overidden to overite existing keys in
prop1 from prop2 while maintaining the keysAsListed List.

15/Mar/04 1:32 AM

16 years, 3 weeks, 2 days ago

18948

No Perforce job exists for this issue.

0

24849

164658

0|i0sjmv:

Commons Collections

COLLECTIONS-82

[collections] Map.debugPrint improvements

Bug

Closed

Major

Fixed

Unassigned

Max Rydahl Andersen

13/Jun/03 18:07

18/Mar/20 02:51

15/Mar/08 21:36

2.1

0

Operating System: other
Platform: Other

debugPrint and verbosePrint in MapUtils makes a cast of the key to a string
(instead of calling toString() on it) which makes it impossible to use for debug
printin maps with keys other than strings.

14/Jun/03 12:35 AM

16 years, 31 weeks, 2 days ago

18916

No Perforce job exists for this issue.

5

20740

164626

0|i0sjfr:

Commons Collections

COLLECTIONS-120

BeanMap.toString() causes infinite loop on circular object graph

Bug

Closed

Major

Fixed

Unassigned

_matthewHawthorne

17/Apr/03 04:46

18/Mar/20 02:51

15/Mar/08 21:36

2.1

0

Operating System: Linux
Platform: Other

This problem is similar to the one in [lang]'s ToStringBuilder.

18/Apr/03 7:28 AM

16 years, 50 weeks, 3 days ago

18878

No Perforce job exists for this issue.

1

19096

164588

0|i0sj7b:

Commons Collections

COLLECTIONS-2

[collections] ExtendedProperties.save(...) does not escape special characters

Bug

Closed

Major

Fixed

Unassigned

Dariusz Wojtas

16/Apr/03 18:28

15/Mar/08 21:35

2.1

0

Operating System: All
Platform: PC

If some value ends with '\', then after saving it, load will fail or will have
incorrect values.
Try to store some property with value ending with '\', eg.

path1=e:\
path2=c:\docs

Look for java.util.Properties on escaping characters.

19/Apr/03 3:42 AM

16 years, 32 weeks, 2 days ago

18996

No Perforce job exists for this issue.

1

19061

164706

0|i0sjxj:

Commons Collections

COLLECTIONS-40

ExtendedProperties.load should default to encoding "8859_1"

Bug

Closed

Major

Fixed

Unassigned

Kirk Wolf

04/Mar/03 03:47

15/Mar/08 21:35

2.1

0

Operating System: All
Platform: All

The default load method for commons.collections.ExtendedProperties currently
loads properties using the default JVM encoding. The default load() method
should use "8859_1" encoding.

Rationale:
1) consistency: java.util.Properties.load() method always uses "8859_1"
2) properties resources are always 8859_1, by convention.
2) On edbcic machines, particularly IBM mainframes, the default encoding is
Cp1047 (ebcdic), but properties files are always ASCII (ISO8859-1)
3) This bug causes many Apache tools, such as Velocity, which uses
commons.collections, to fail on non-ascii machines, since they distribute
properties resources which are (correctly) in 8859-1.

13/Mar/03 1:01 AM

16 years, 50 weeks, 3 days ago

18958

No Perforce job exists for this issue.

1

17616

164668

0|i0sjp3:

Commons Collections

COLLECTIONS-105

StaticBucketMap.remove(Object) incorrectly handles key comparison

Bug

Closed

Major

Fixed

Unassigned

leo.sutic

18/Feb/03 02:15

15/Mar/08 21:36

2.1

0

Operating System: other
Platform: Other

I've found a bug in the StaticBucketMap class, the remove(Object)
method:

/**
* Implements {@link Map#remove(Object)}.
*/
public Object remove( Object key )
{
int hash = getHash( key );

synchronized( m_locks[ hash ] )
{
Node n = m_buckets[ hash ];
Node prev = null;

while( n != null )
{
HERE>>>>>>>>> if( n.key == null || ( n.key != null && n.key.equals(
key ) ) ) <<<<<<<<<<<<<<<<<<
{
// Remove this node from the linked list of nodes.
if( null == prev )
{
// This node was the head, set the next node to
be the new head.
m_buckets[ hash ] = n.next;
}
else
{
// Set the next node of the previous node to be
the node after this one.
prev.next = n.next;
}
m_locks[hash].size--;
return n.value;
}

prev = n;
n = n.next;
}
}

return null;
}

The test is:

if( n.key == null || ( n.key != null && n.key.equals(
key ) ) )

should be:

if( n.key == key || ( n.key != null && n.key.equals( key
) ) )

which is how it works in get(Object), containsKey(Object) etc. and which
is correct. We have a match if the keys match using == OR if they are
equal according to equals().

23/Feb/03 12:37 AM

17 years, 6 weeks, 3 days ago

18893

No Perforce job exists for this issue.

0

17139

164603

0|i0sjan:

Commons Collections

COLLECTIONS-91

[collections] CollectionWrapper should implement Serializable

Bug

Closed

Minor

Duplicate

Unassigned

sean schofield

18/Nov/03 05:22

15/Mar/08 21:36

14/Jul/06 12:07

2.1

1

0

Operating System: All
Platform: All

The CollectionWrapper inner class (part of CollectionUtils) should implement
Serializable. This would allow the creation of serializable lists in the event
that the user needs this functionality. Making this change would assume that
all the objects contained in the list were serializable (not a big deal IMO.)

I discovered this problem when using ListUtils.lazyList() method. The
resulting list is not serializable and I need it to be.

13/Jan/04 11:03 AM

13 years, 37 weeks, 4 days ago

18907

No Perforce job exists for this issue.

0

24762

164617

0|i0sjdr:

Commons Collections

COLLECTIONS-62

ReferenceMap contract

Bug

Closed

Major

Fixed

Unassigned

Eduardo Francos

27/Nov/02 17:50

15/Mar/08 21:35

2.1

0

Operating System: All
Platform: All

I switched from SoftRefHashMap to ReferenceMap and I noticed that the purge
method as become private and is called in many places in the source code, but
the documentation for the method states that it is called only for write operations.
I must be sure that the stale mappings are removed for read operations too
(ex:size) and though currently the implementation calls purge() for all read
methods as well this may change in the future.
I think that calling purge on all [relevant] public methods is the right
approach to preserve a coherent state.

25/Jan/03 8:35 PM

17 years, 10 weeks, 3 days ago

18936

No Perforce job exists for this issue.

0

14889

164646

0|i0sjk7:

Commons Collections

COLLECTIONS-73

BeanMap.putAllWriteable() does not count the write only methods

Bug

Closed

Major

Fixed

Unassigned

Dimiter Dimitrov

09/Jan/03 02:26

15/Mar/08 21:36

2.1

0

Operating System: All
Platform: All

BeanMap.putAllWriteable(BeanMap) method, the java doc does not describe the implementation
correctly.
According to Sun a property could be defined by getter OR mutator. The current
implementation of the method assumes that a property always should have getter.

/**
*
Puts all of the writeable properties from the given BeanMap into this
* BeanMap. Read-only
properties will be ignored.
*/
public void putAllWriteable(BeanMap map) {
Iterator
readableKeys = map.readMethods.keySet().iterator();
while(readableKeys.hasNext())
{
Object key = readableKeys.next();
if(getWriteMethod(key) != null) {
this.put(key,
map.get(key));
}
}
}

I have an adapter bean which have a mutator which accepting a
long value (actualy a bit vector) And few boolean accessors which retrieve the actual values.
Now I'm replacing my own utility classes with jakarta commons and I find that these issues make
them nearly unusable for me :(

I suggest to change the method to:

public void
putAllWriteable(BeanMap map) {
Iterator writableEntries =
map.writeMethods.entrySet().iterator();
while(writableEntries.hasNext()){

Map.Entry writableEntry = (Map.Entry) writableEntries.next();

writeMethods.put(writableEntry.getKey(), writableEntry.getValue());
}
}

25/Jan/03 8:10 PM

17 years, 10 weeks, 3 days ago

18925

No Perforce job exists for this issue.

1

15897

164635

0|i0sjhr:

Commons Collections

COLLECTIONS-22

[collections] In BeanMap all properties are writable (some with null mutator)

Bug

Closed

Major

Fixed

Unassigned

Dimiter Dimitrov

09/Jan/03 01:24

15/Mar/08 21:35

2.1

0

Operating System: All
Platform: All

In BeanMap.initialize() method there is a bug that causes all properties to have write methods
(even if they are null).

23/Mar/05 8:30 AM

15 years, 1 week, 6 days ago

18976

No Perforce job exists for this issue.

1

15895

164686

0|i0sjt3:

Commons Collections

COLLECTIONS-734

Encountered an IllegalStateException while traversing with Flat3Map.entrySet()

Bug

Resolved

Major

Fixed

Unassigned

Chen

11/Nov/19 08:07

05/Dec/19 16:13

3.0

4.5

Map

0

1

0

1200

Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
{code:java}
//代码示例
public void testEntrySet() {
final Flat3Map<Integer, String> map = new Flat3Map<>();
map.put(1, "A");
map.put(2, "B");
map.put(3, "C");
Iterator<Map.Entry<Integer, String>> it = map.entrySet().iterator(); Map.Entry<Integer, String> mapEntry1 = it.next();
Map.Entry<Integer, String> mapEntry2 = it.next();
Map.Entry<Integer, String> mapEntry3 = it.next();
it.remove(); assertEquals(2, map.size());
}
{code}
Using the above code will generate an IllegalStateException.
The reason for this problem is that there is a problem with the EntryIterator.remove() method in the Flat3Map java class.

I submitted a [PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115) to fix this bug.

100%

1200

0

05/Dec/19 4:13 PM

14 weeks, 5 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z08gjk:

Commons Collections

COLLECTIONS-580

Arbitrary remote code execution with InvokerTransformer

Bug

Closed

Major

Fixed

Unassigned

Philippe Marschall

07/Nov/15 13:28

18/Mar/20 02:57

24/Jul/19 18:56

21/Nov/15 10:02

3.0, 4.0

3.2.2, 4.1

66

104

COLLECTIONS-583, VELTOOLS-169, COLLECTIONS-721, HADOOP-12579, IO-487, MYFACES-4020, KARAF-4135

With {{InvokerTransformer}} serializable collections can be build that execute arbitrary Java code. {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes {{#entrySet}} and {{#get}} on a deserialized collection. If you have an endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you can combine the two to create arbitrary remote code execution vulnerability.

I don't know of a good fix short of removing {{InvokerTransformer}} or making it not Serializable. Both probably break existing applications.

This is not my research, but has been discovered by other people.

https://github.com/frohoff/ysoserial

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

08/Nov/15 4:55 PM

4 years, 15 weeks ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

0|i2o3kf:

Commons Collections

COLLECTIONS-581

Deserialization and Apache Commons Collection

Bug

Closed

Major

Invalid

Mark Thomas

Deepesh

10/Nov/15 09:55

18/Mar/20 02:55

27/Nov/15 21:47

10/Nov/15 10:00

3.0, 3.1, 3.2.1

Functor

0

1

Hi Team,

This is regarding “commons-collections Java library”. In our applications we are widely using this library and hence looking to urgently patch the fix for vulnerability issue if it is available.
Searching on internet we found one patch released on Sunday 08th Nov http://svn.apache.org/viewvc?view=revision&revision=1713307

Just wanted to check with you if there is any updated / complied version of commons-collections jar available or going to be released soon which we can directly replace with our existing jar file that provides the fix for the vulnerability issue.

Thanks in advance!

patch

10/Nov/15 10:00 AM

4 years, 19 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Patch, Important

0|i2o6qn:

Commons Collections

COLLECTIONS-384

Inconsistent Javadoc comment and code for synchronizedMap(Map) in org.apache.commons.collections.MapUtils

Bug

Closed

Major

Fixed

Unassigned

SHIN HWEI TAN

26/Oct/11 20:21

18/Mar/20 02:41

09/Nov/14 14:31

29/Oct/11 20:54

3.0, 3.1, 3.2

4.0-alpha1, 4.0

Collection

0

300

0%

Platform independent

The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null":
/**
...
* @param map the map to synchronize, must not be null
* @return a synchronized map backed by the given map
* @throws IllegalArgumentException if the map is null
*/
public static Map synchronizedMap(Map map) {
return Collections.synchronizedMap(map);
}

However, the method throws NullPointerException instead of IllegalArgumentException when called with null.

Suggested Fixes:
1. Add code "if (map == null) throw IllegalArgumentException();" at the beginning of the method body.
or
2. Change "@throws IllegalArgumentException if the map is null" to "@throws NullPointerException if the map is null".
or
3. Remove the entire "@throws IllegalArgumentException if the map is null".

0%

300

code, javadoc, synchronizedMap

29/Oct/11 8:52 PM

8 years, 21 weeks, 3 days ago

214815

No Perforce job exists for this issue.

0

164371

0|i0shv3:

Commons Collections

COLLECTIONS-352

AbstractCollectionDecorator is inconsistent with AbstractListDecorator. Uses private member variable instead of protected getter

Bug

Closed

Minor

Fixed

Unassigned

Adam Gent

10/Feb/10 20:34

09/Nov/14 14:31

28/Feb/13 20:05

3.0, 3.1, 3.2

4.0-alpha1, 4.0

Collection

0

1

AbstractListDecorator uses getList() to access its private member variable for its methods:
{code}
public int indexOf(Object object) {
return getList().indexOf(object);
}
{code}

Which allows me to almost do something like this (notice I'm taking some liberties here with the no-arg serialization constructor):

{code}
public static class FutureList<T> extends AbstractListDecorator {

private Future<List<T>> futureList;

public FutureList(Future<List<T>> futureList)
{
super();
this.futureList = futureList;
}

@Override
protected Collection<T> getCollection()
{
try
{
return futureList.get();
}
catch (InterruptedException e)
{
throw new RuntimeException(e);
}
catch (ExecutionException e)
{
throw new RuntimeException(e);
}
}
}
{code}

But AbstractCollectionDecorator uses its private member variable
{code}
public boolean add(Object object) {
return collection.add(object);
}
{code}

When it should be IMHO:

{code}
public boolean add(Object object) {
return getCollection().add(object);
}
{code}

Of course most everybody has an armpit and an opinion :)

19/Jun/10 7:25 PM

9 years, 40 weeks, 3 days ago

18651

No Perforce job exists for this issue.

0

164393

0|i0shzz:

Commons Collections

COLLECTIONS-98

[collections] BlockingBuffer Should Include Cause Exception When Throwing BufferUnderflowException

Bug

Closed

Major

Fixed

Unassigned

Seth Ladd

23/Feb/05 06:22

15/Mar/08 21:36

3.0

0

Operating System: All
Platform: All

The code for BlockingBuffer throws BufferUnderflowException when a
InterruptedException is thrown. But, the original InterruptedException is not
included or wrapped by the new BufferUnderflowException. This makes it
difficult to determine if the thread was truly interrupted.

I believe the commons project has support for wrapping exception (to support
older JVMs). This would be very helpful to support.

For instance, line 141 of the 3.0 version of BlockingBuffer.

Thanks!

15/May/05 6:36 PM

14 years, 46 weeks, 1 day ago

18900

No Perforce job exists for this issue.

0

33700

164610

0|i0sjc7:

Commons Collections

COLLECTIONS-118

[collections] LRUMap.removeLRU(LinkEntry) is passed wrong link entry

Bug

Closed

Major

Fixed

Unassigned

meurig sage

16/Apr/04 20:51

15/Mar/08 21:36

3.0

0

Operating System: Windows XP
Platform: PC

The following program attempts to add 3 entries (a,b,c) to an LRUMap with max
size two.

The contents of the LRUMap are always correct but when the LRUMap fills up it
removes entry "a" but passes entry "b" to the removeLRU method.

run:
[java] [a]
[java] [a, b]
[java] Remove lru b
[java] [b, c]

import org.apache.commons.collections.map.LRUMap;

public class LRUMapTest {
public static void main (String[] args) {
LRUMap map = new LRUMap(2) {
protected boolean removeLRU(LinkEntry entry) {
System.out.println("Remove lru "+entry.getKey());
return true;
}
};
map.put("a","a");
System.out.println(map.keySet());
map.put("b","b");
System.out.println(map.keySet());
map.put("c","c");
System.out.println(map.keySet());
}
}

17/Apr/04 6:55 AM

15 years, 50 weeks, 3 days ago

18880

No Perforce job exists for this issue.

0

28433

164590

0|i0sj7r:

Commons Collections

COLLECTIONS-115

Flat3Map doesn't implement Serializable

Bug

Closed

Major

Fixed

Unassigned

Manik Surtani

25/Mar/04 22:39

14/Jul/06 05:44

3.0

3.1

0

Operating System: Linux
Platform: All

A very useful hish performance map. Sadly I cannot use it in my J2EE env
because it isn't seriabilable and hence cannot be a parameter in any remote calls.

Is there a specific reason as to why this isn't Serializable, or was this
something that was overlooked?

01/Apr/04 7:20 AM

16 years, 4 days ago

18883

No Perforce job exists for this issue.

0

27946

164593

0|i0sj8f:

Commons Collections

COLLECTIONS-32

[collections] DualTreeBidiMap does not sort with custom Comparator

Bug

Closed

Major

Fixed

Unassigned

Jonas Van Poucke

11/Jun/04 15:47

15/Mar/08 21:35

3.0

3.1

0

Operating System: other
Platform: Other

When you supply a Comparator to the constructor of DualTreeBidiMap, the custom
sorting order is NOT maintained.

The problem lies in the order where
protected Map createMap()
is called: The constructors in AbstractDualBidiMap call this metod, but the
comparator is set *after* calling super() in DualTreeBidiMap:

//--- Class AbstractDualBidiMap---//
protected AbstractDualBidiMap() {
super();
maps[0] = createMap();
maps[1] = createMap();
}
//--- Class DualTreeBidiMap ---//
public DualTreeBidiMap(Comparator comparator) {
super();
this.comparator = comparator; // <-- Too late, createMap already called!
}
protected Map createMap() {
return new TreeMap(comparator); // <-- Comparator always null
}

Hence, DualTreeBidiMap.compatator() always returns null.

12/Jun/04 6:32 AM

15 years, 42 weeks, 1 day ago

18966

No Perforce job exists for this issue.

0

29519

164676

0|i0sjqv:

Commons Collections

COLLECTIONS-81

[collections] Open Patch 25553 for version 3.0

Bug

Closed

Major

Incomplete

Unassigned

Stefan DAMIAN

07/Jun/04 19:46

15/Mar/08 21:36

3.0

0

Operating System: other
Platform: Other

Patch 25553 wasn't corrected in collection - final version 3.0

08/Jun/04 3:18 AM

14 years, 40 weeks, 3 days ago

18917

No Perforce job exists for this issue.

0

29423

164627

0|i0sjfz:

Commons Collections

COLLECTIONS-130

[collections] CollectionUtils.cardinality should be made smarter about Bag

Bug

Closed

Major

Fixed

Unassigned

Jon Schewe

27/Apr/04 21:37

15/Mar/08 21:36

3.0

0

Operating System: other
Platform: Other

I see that Bag implementations have a getCount() method that one would presume
is more efficient than iterating over the objects in the Collection. Why
doesn't CollectionUtils.cardinality() take advantage of this?

28/Apr/04 3:03 AM

15 years, 48 weeks, 6 days ago

18868

No Perforce job exists for this issue.

0

28629

164578

0|i0sj53:

Commons Collections

COLLECTIONS-24

[collections] [patch] TransformingPredicate

Bug

Closed

Major

Fixed

Unassigned

Alban Peignier

15/Feb/04 05:47

15/Mar/08 21:35

3.0

0

Operating System: other
Platform: Other

A Predicate which transforms the given object before evaluating the result with
another Predicate :

public boolean evaluate(Object object) {
Object result = transformer.transform(object);
return predicate.evaluate(result);
}

14/Mar/04 12:36 AM

16 years, 3 weeks, 3 days ago

18974

No Perforce job exists for this issue.

1

26946

164684

0|i0sjsn:

Commons Collections

COLLECTIONS-27

[collections] LRUMap.clone() broken?

Bug

Closed

Major

Fixed

Unassigned

Fabrizio Giustina

23/Feb/04 22:21

15/Mar/08 21:35

3.0

0

Operating System: other
Platform: Other

LRUMap.clone() always produces an empty Map. Shouldn't it produce a shallow
copy with all the entries?

This test actually fails in 3.0:

public void testLRUMapClone()
{
LRUMap lru = new LRUMap(10);
lru.put("1", "1");

Map lruClone = (Map) lru.clone();

assertEquals(lru.size(), lruClone.size());
}

27/Feb/04 8:26 AM

16 years, 5 weeks, 4 days ago

18971

No Perforce job exists for this issue.

0

27159

164681

0|i0sjrz:

Commons Collections

COLLECTIONS-95

[collections] fails the method TransformedMap.transformedMap

Bug

Closed

Major

Fixed

Unassigned

Tirso Canela

31/Aug/04 19:41

15/Mar/08 21:36

3.0

0

Operating System: other
Platform: Other

This methods instance a TransformedMap but it doesn't do anything.
The method transformMap must be called internally.

01/Sep/04 8:20 AM

14 years, 37 weeks, 3 days ago

18903

No Perforce job exists for this issue.

1

30959

164613

0|i0sjcv:

Commons Collections

COLLECTIONS-132

Input streams are never closed in ExtendedProperties

Bug

Closed

Major

Fixed

Unassigned

Lars Beuster

17/Mar/04 20:59

15/Mar/08 21:36

3.0

0

Operating System: other
Platform: Other

If I read a file with ExtendedProperties the OS cannot remove this file as long
as my JVM is running because it has still a handle on that file.

18/Mar/04 5:12 AM

16 years, 2 weeks, 5 days ago

18866

No Perforce job exists for this issue.

0

27737

164576

0|i0sj4n:

Commons Collections

COLLECTIONS-599

HashEntry array object naming data initialized with double the size during deserialization

Bug

Closed

Critical

Fixed

Unassigned

Tejas Patel

02/Dec/16 11:58

05/Jul/19 15:47

3.1

4.1

Collection, Map

0

4

Common collections 3.1 and 3.2 are used at many places and frameworks including struts2.
Supose a LinkedMap object it is created and have size greater than zero is serialized. While deserializing this object , array of HashEntry naming data delacred in AbstractHashedMap always initialises with a new capacity of double its double of the serialized object.

Please see the below API declared in AbstractHashedMap class :

{code:java}
protected void checkCapacity()
{
if (this.size >= this.threshold)
{
int newCapacity = this.data.length * 2;
if (newCapacity <= 1073741824) {
ensureCapacity(newCapacity);
}
}
}
{code}

06/Nov/17 6:16 AM

2 years, 6 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Important

0|i372nr:

Commons Collections

COLLECTIONS-358

CollectionUtils.removeAll(Collection collection, Collection remove) calls ListUtils.retainAll(collection, remove)

Bug

Closed

Major

Duplicate

Unassigned

Andreas Knees

29/Jun/10 21:35

29/Jun/10 23:38

3.1

Collection

0

COLLECTIONS-357

any

Inside CollectionUtils.removeAll(Collection collection, Collection remove) the retainAll() method of ListUtils is called in line 1122.
It should read ListUtils.removeAll(collection, remove) instead.

Workaround: use ListUtils.removeAll(Collection collection, Collection remove) instead.

9 years, 39 weeks ago

18645

No Perforce job exists for this issue.

0

164389

0|i0shz3:

Commons Collections

COLLECTIONS-250

containsKey on MultiHashMap seems incorrect

Bug

Closed

Critical

Invalid

James Carman

Nikhil G. Daddikar

27/Apr/07 10:24

15/Mar/08 21:36

30/Apr/07 10:56

3.1, 3.2

Map

0

2

MultiHashMap m = new MultiHashMap();
m.putAll("key", Collections.EMPTY_LIST);
System.out.println(m.containsKey("key"))

It says false, when it should have printed true.

The problem is that the code in MultiHashMap and even MultiValueMap has in putAll():

if (values == null || values.size() == 0)
{
return false;
}

This means that they key is never being entered into the Map. This is causing a huge problem because the behaviour has changed.

27/Apr/07 7:39 PM

12 years, 48 weeks, 1 day ago

18749

No Perforce job exists for this issue.

0

164472

0|i0sihj:

Commons Collections

COLLECTIONS-316

LRUMap constructor javadoc and behavior are inconsistent (maxSize cannot be less than 0)

Bug

Closed

Minor

Fixed

Unassigned

ori

10/Feb/09 21:55

09/Nov/14 14:31

28/Feb/13 20:04

3.1

4.0-alpha1, 4.0

Map

0

60

0%

n/a

The LRUMap constructor specifies "@param maxSize the maximum size of the map, -1 for no limit"

The first line is then:

if (maxSize < 1) {
throw new IllegalArgumentException("LRUMap max size must be greater than 0");
}

There is nothing wrong with allowing a negative maxSize. This way the map can be used to order elements relative to access time. I think the above code should be remove and the javadoc should stay the same.

0%

60

20/May/09 4:22 AM

10 years, 44 weeks, 6 days ago

18685

No Perforce job exists for this issue.

0

164421

0|i0si67:

Commons Collections

COLLECTIONS-111

IteratorChain skips over elements in iterator

Bug

Closed

Major

Cannot Reproduce

Unassigned

Jonathan Giles

21/Jan/06 10:12

28/Feb/13 19:52

19/Mar/08 06:52

3.1

Iterator

0

Operating System: Windows XP
Platform: PC

Hi there,
When using the IteratorChain class to add multiple iterators, it appears that
using itChain.hasNext() and itChain.next() skips a number of elements in the
iterator at each step.

Given a single iterator of 7 elements, and using the following code:

private IteratorChain buildIterator() {
// this iterator contains the children of the current object only
Iterator it = getChildren(p);

// we use an IteratorChain to add multiple iterators together without the
overhead of copying
IteratorChain itChain = new IteratorChain(it);

return itChain;
}

and then simply
IteratorChain it = treeModel.getAllTreeNodes(obj);

// FIXME this only prints one or two of the results, which is a bug!
while (it.hasNext())
System.out.println(": " + it.next().getClass());

I put in 7 elements, but only get 2 out - the 2nd and the last elements. It
appears that through my debugging that the nextClause variable is updated even
when the hasNext() function is called.

Also, if I put 7 system.out.println statements, all elements are printed as normal.

21/Jan/06 10:52 AM

12 years, 1 week, 6 days ago

18887

No Perforce job exists for this issue.

0

38341

164597

0|i0sj9b:

Commons Collections

COLLECTIONS-69

[collections] Comparable on AbstractKeyValue

Bug

Closed

Major

Won't Fix

Unassigned

Shishir

03/Jan/05 01:54

15/Mar/08 21:35

3.1

0

Operating System: All
Platform: All

Can either the AbstractKeyValue or DefaultKeyValue implement Comparable. Many a
times, the KeyValue needs to be sorted on key,value and don't want to have
screate a new Comparator in order to sort it

04/Jan/05 9:17 AM

15 years, 13 weeks ago

18929

No Perforce job exists for this issue.

0

32914

164639

0|i0sjin:

Commons Collections

COLLECTIONS-30

[collections] TransformedMap.putAll fails with empty Map

Bug

Closed

Major

Duplicate

Unassigned

Paul Libbrecht

09/Feb/06 22:45

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: Other

Using collections 3.1, TransformedMap.putAll creates a new LinkedMap with the
size of the parameter's collection as capacity. When this size is zero, however,
this raises exceptions.

paul

09/Feb/06 11:44 PM

14 years, 7 weeks, 5 days ago

18968

No Perforce job exists for this issue.

0

38591

164678

0|i0sjrb:

Commons Collections

COLLECTIONS-72

[collections] java.lang.ArrayIndexOutOfBoundsException

Bug

Closed

Major

Duplicate

Unassigned

Stijn Christiaens

08/Feb/06 20:03

15/Mar/08 21:36

3.1

0

Operating System: other
Platform: Other

In BoundedFifoBuffer (line 340):

// Other elements require us to shift the subsequent elements

int i = lastReturnedIndex + 1;

while (i != end) {

if (i >= maxElements) {

elements[i - 1] = elements[0];

i = 0;

} else {

elements[i - 1] = elements[i];

i++;

}

}
An AIOOBException is thrown at line 347 when trying to remove an element and i = 0.

08/Feb/06 11:21 PM

14 years, 7 weeks, 6 days ago

18926

No Perforce job exists for this issue.

0

38565

164636

0|i0sjhz:

Commons Collections

COLLECTIONS-113

[collections] ExtendedProperties#convertProperties doesn't inherit defaults.

Bug

Closed

Major

Fixed

Unassigned

Shinobu Kawai

13/Nov/04 00:44

02/May/13 02:28

15/Mar/08 21:36

3.1

0

VELOCITY-333

Operating System: other
Platform: Other

ExtendedProperties#convertProperties() uses props.keys() instead of
props.propertyNames(), causing the defaults properties to be discarded.

23/May/05 8:05 AM

14 years, 45 weeks, 1 day ago

18885

No Perforce job exists for this issue.

2

32204

164595

0|i0sj8v:

Commons Collections

COLLECTIONS-18

[collections] ListOrderedSet broken or documentation wrong.

Bug

Closed

Minor

Fixed

Unassigned

Rohan Lenard

05/Nov/04 08:45

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: All

The method ListOrderedSet.decorate(List list) "decorates" the list, implying
that it leaves the underlying list un-modified. But this is just not true - it
requires a modifiable List so it can remove duplicates. It should at least
warn about this - so you don't have to look in the code to see how it works and
see why it fails when using an unmodifiable list (such as given by
java.util.Collections.unmodifiableList()).

Actually it'd be good to have a variant that worked with unmodifiable lists.

04/Jan/05 9:02 AM

15 years, 13 weeks ago

18980

No Perforce job exists for this issue.

0

32073

164690

0|i0sjtz:

Commons Collections

COLLECTIONS-61

[collections] FilterIterator doesn't reset when properties are set

Bug

Closed

Major

Fixed

Unassigned

Huw Roberts

30/Dec/05 05:14

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: Other

Test case follows:

[pre]
/**
* Test that when the iterator is changed, the hasNext method
* returns the correct response for the new iterator.
*/
public void testSetIterator() {
Iterator iter1 = Collections.singleton(new Object()).iterator();
Iterator iter2 = Collections.EMPTY_LIST.iterator();

FilterIterator filterIterator = new FilterIterator(iter1);
filterIterator.setPredicate(TruePredicate.getInstance());

assertTrue("filterIterator should have an element",
filterIterator.hasNext());

filterIterator.setIterator(iter2);

assertTrue("filterIterator should not have an element", !
filterIterator.hasNext());
}

/**
* Test that when the predicate is changed, the hasNext method
* returns the correct response for the new predicate.
*/
public void testSetPredicate() {
Iterator iter = Collections.singleton(null).iterator();

FilterIterator filterIterator = new FilterIterator(iter);
filterIterator.setPredicate(TruePredicate.getInstance());

assertTrue("filterIterator should have an element",
filterIterator.hasNext());

filterIterator.setPredicate(NotNullPredicate.getInstance());

assertTrue("filterIterator should not have an element", !
filterIterator.hasNext());
}
[/pre]

30/Dec/05 5:25 AM

14 years, 12 weeks, 3 days ago

18937

No Perforce job exists for this issue.

0

38074

164647

0|i0sjkf:

Commons Collections

COLLECTIONS-38

[collections] Javadoc entry page overview has bad links for 'Transformer' and 'Factory'

Bug

Closed

Trivial

Fixed

Unassigned

andreas przygienda

02/Jun/05 22:04

15/Mar/08 21:35

3.1

0

Operating System: All
Platform: All

the overview in the entry page of the collections API javadoc has bad links in
the description of the "org.apache.commons.collections.functors" package.
(*...* means an underlying link):

"This package contains implementations of the *Closure*, *Predicate*,
*Transformer* and *Factory* interfaces."

*Transformer* and *Factory* link to the Predicate Interface

07/Jun/05 8:05 AM

14 years, 43 weeks ago

18960

No Perforce job exists for this issue.

0

35186

164670

0|i0sjpj:

Commons Collections

COLLECTIONS-33

[collections] AbstractHashedMap: initial threshold too conservative

Bug

Closed

Major

Fixed

Unassigned

Christian Siefkes

23/May/05 00:28

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: All

The (int initialCapacity, float loadFactor) constructor of
org.apache.commons.collections.map.AbstractHashedMap calculates the initial
resize too threshold conservatively, based on the requested initial capacity
instead of the actually chosen initial capacity (which is round up to the next
power of too). This could be fixed switching two lines to calculating the
initial threshold after rounding up the capacity instead of before:

--- AbstractHashedMap.java 2005-05-22 17:04:23.000000000 +0200
+++ AbstractHashedMap-patched.java 2005-05-22 17:08:46.000000000 +0200
@@ -147,4 +147,4 @@
this.loadFactor = loadFactor;
- this.threshold = calculateThreshold(initialCapacity, loadFactor);
initialCapacity = calculateNewCapacity(initialCapacity);
+ this.threshold = calculateThreshold(initialCapacity, loadFactor);
this.data = new HashEntry[initialCapacity];

A map with an requested capacity of 600 and a load factor of 0.75, will start
with an initial array of length 1024. Without the fix, the array will be resized
for the first time as soon as there are 450 entries, i.e. the array is less than
45% filled instead of the 75% suggested by the load factor.

23/May/05 2:49 AM

14 years, 45 weeks, 2 days ago

18965

No Perforce job exists for this issue.

0

35012

164675

0|i0sjqn:

Commons Collections

COLLECTIONS-70

[collections] TreeList Collections.binarySearch problem - general remove() after previous() problem

Bug

Closed

Major

Fixed

Unassigned

Tomas D.

08/Jun/05 06:21

15/Mar/08 21:36

3.1

0

Operating System: Windows XP
Platform: Other

Sometimes TreeList crashes if i tried to call:
Collections.binarySearch(queue, n, comp);
with ArrayList is everything ok.

Exception in thread "main" java.lang.NullPointerException
at
org.apache.commons.collections.list.TreeList$TreeListIterator.previous
(TreeList.java:841)
at java.util.Collections.get(Unknown Source)
at java.util.Collections.iteratorBinarySearch(Unknown Source)
at java.util.Collections.binarySearch(Unknown Source)
at utils.queue.QueueSorted.put(QueueSorted.java:51)
at framework.search.GraphSearch.solve(GraphSearch.java:53)
at search.informed.BestFirstSearch.solve(BestFirstSearch.java:20)
at Hlavni.main(Hlavni.java:66)

09/Jul/05 10:37 AM

14 years, 10 weeks, 3 days ago

18928

No Perforce job exists for this issue.

3

35258

164638

0|i0sjif:

Commons Collections

COLLECTIONS-12

ListOrderedSet add results in separate objects in set/list if equal

Bug

Closed

Major

Cannot Reproduce

Stephen Colebourne

Gene Hart

03/Nov/05 07:59

19/Jul/06 22:01

3.1

Set

0

Operating System: other
Platform: Other

If you add an object to ListOrderedSet, and then try to replace the object with
add and the objects are different but equals() is true, you will have two
different objects in the internal list and set so after you do an add, doing a
listorderedset.get(i) will return the old object.

04/Nov/05 8:05 AM

13 years, 36 weeks, 6 days ago

18986

No Perforce job exists for this issue.

0

37338

164696

0|i0sjvb:

Commons Collections

COLLECTIONS-93

[collections] When the AbstractHashedMap is serialized and deserialized the data array doubles its size

Bug

Closed

Major

Fixed

Unassigned

Marcos Cesar de Oliveira

02/Apr/05 03:19

15/Mar/08 21:36

14/Jul/06 12:04

3.1

1

0

Operating System: Windows XP
Platform: PC

In the method "AbstractHashMap#doReadObject", the method call "threshold =
calculateThreshold(data.length, loadFactor);" is after the "put(key, value);".
The "put" method uses the threshold to check the capacity of the data array.
In this checking, the threshold is zero, leading to a resize of the data array.
At each serialization/deserialization the size of the data array doubles.

08/May/05 3:05 AM

13 years, 37 weeks, 4 days ago

18905

No Perforce job exists for this issue.

0

34265

164615

0|i0sjdb:

Commons Collections

COLLECTIONS-77

[collections] IteratorChain.remove() in combination with FilterIterator

Bug

Closed

Major

Fixed

Unassigned

Peter Billen

02/Apr/05 03:52

15/Mar/08 21:36

3.1

0

Operating System: Windows XP
Platform: Other

IteratorChain.remove() throws IllegalStateException when one of the underlying
iterators is a FilterIterator

code:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgNo=64950

03/Apr/05 5:18 AM

14 years, 46 weeks ago

18921

No Perforce job exists for this issue.

2

34267

164631

0|i0sjgv:

Commons Collections

COLLECTIONS-49

[collections] Compile Errors when Importing in VAJ 4

Bug

Closed

Major

Won't Fix

Unassigned

David Müller

08/Apr/05 18:48

15/Mar/08 21:35

3.1

0

Operating System: Windows 2000
Platform: PC

Hi,
when I try to import Collections Framework into IBM VisualAge for Java (VAJ) 4,
I get loads of Compile Errors.
(For your information: VAJ is Java 1.2.2 based...)

Most Errors are in the Testing Framework, so could be ignored.
However, there are quite a few Errors from using

Entry

instead of

Map.Entry,

for Example in

AbstractReferenceMap
public Object get(Object key) {
purgeBeforeRead();
Entry entry = getEntry(key);
if (entry == null) {
return null;
}
return entry.getValue();
}

It would be nice for less adventurous users not to have to change the source
code in order to use this in VAJ.

I can send you the changed sources.

Yours,
David

P.S.: The severity "major" is debatable... 8-)

09/May/05 12:21 AM

14 years, 45 weeks, 1 day ago

18949

No Perforce job exists for this issue.

0

34368

164659

0|i0sjn3:

Commons Collections

COLLECTIONS-88

[collection] Map filter with MapUtils.predicatedMap feature request

Bug

Closed

Major

Won't Fix

Unassigned

Luc Carpentier

14/Apr/05 15:32

03/May/11 00:36

15/Mar/08 21:36

3.1

0

Operating System: other
Platform: Other

Hello,

I stumbled into the following problem:

A client submits an http request with prefixed parameters. Each prefix will
have it's own javabean to populate. So if there are two prefixes, then there
will be two different javabeans to populate from the request parameters.

I created a PrefixPredicate that only allows values with a specific prefix. I
then used this PrefixPredicate to copy the Map with the request parameters to
a predicated Map with:

Map predicatedMap = MapUtils.predicatedMap(dataMap,keyPredicate,null);

However, since the request parameters contain parameters with other prefixes
as well, this returns an IllegalArgumentException.

It would be nice to be able to specify to the MapUtils.predicatedMap method to
ignore entries that do not comply to the predicate instead of to throw an
exception.

There are lots of possabilities to filter on a Collection, but a Map is not a
collection...

23/May/05 3:04 AM

8 years, 47 weeks, 1 day ago

18910

No Perforce job exists for this issue.

0

34446

164620

0|i0sjef:

Commons Collections

COLLECTIONS-3

NPE: map.LRUMap.reuseMapping(LRUMap.java:272)

Bug

Closed

Major

Cannot Reproduce

Unassigned

Otis Gospodnetic

08/Dec/04 03:39

28/Feb/13 19:53

17/Jun/09 09:48

3.1

Map

2

0

COLLECTIONS-330

Operating System: Linux
Platform: PC

I'm using Collections 3.1 and just found this NPE in my logs:

java.lang.NullPointerException
at
org.apache.commons.collections.map.LRUMap.reuseMapping(LRUMap.java:272)
at
org.apache.commons.collections.map.LRUMap.addMapping(LRUMap.java:243)
at
org.apache.commons.collections.map.AbstractHashedMap.put(AbstractHashedMap.java:282)

I instantiated LRUMap like this:

LRUMap map = new LRUMap(31);

And from there on, I use it like I'd use any Map, putting things into
it, and so on. Maybe I'm not using LRUMap correctly? My _guess_ is
that this occurs when the Map is full, but I am not certain.

I am wrapping the LRUMap in my own Maps as follows, but I think they're
not the culprit:

LRUMap map = new LRUMap(31);
_userSessions = new ExpiringMap(map,
new TimerTTLReferenceHolder(1800000), // ttl=30min
300000); // purge frequency=5min

The only similar thing I found is COM-1288, but it looks like that was fixed
before 3.1 release.

I understand the value of a self-contained unit test that demonstrates this bug,
but it happens only occassionally on my production system, never during
development, so I can't really come up with it :(

My guess is that this is a boundary case, as line 272 is:

loop = loop.next;

So 'loop' is most likely null, and it's null because ... not sure, maybe that
hashIndex is wrong.

04/Feb/05 9:28 AM

10 years, 40 weeks, 6 days ago

18995

No Perforce job exists for this issue.

3

32573

164705

0|i0sjxb:

Commons Collections

COLLECTIONS-123

[collections] StaticBucketMap#containsKey(final Object key) can return illegal value.

Bug

Closed

Major

Fixed

Unassigned

Kazuya Ujihara

20/Nov/05 18:18

15/Mar/08 21:36

3.1

0

Operating System: Windows XP
Platform: All

org.apache.commons.collections.map.StaticBucketMap#containsKey("any string")
can return true by mistake when null key is containing in buckets.
I think containsKey(Object) method has to be modified like the following.

public boolean containsKey(final Object key) {
int hash = getHash(key);

synchronized (locks[hash]) {
Node n = buckets[hash];

while (n != null) {
- if (n.key == null || (n.key != null && n.key.equals(key))) {
+ if ((n.key == null && key == null) || (n.key != null &&
n.key.equals(key))) {
return true;
}

n = n.next;
}
}
return false;
}

Kazuya Ujihara

23/Nov/05 7:28 AM

14 years, 18 weeks, 6 days ago

18875

No Perforce job exists for this issue.

0

37567

164585

0|i0sj6n:

Commons Collections

COLLECTIONS-134

[collections] Error in deserialization of full BoundedFifoBuffer

Bug

Closed

Major

Duplicate

Unassigned

Tilmann Kuhn

17/Nov/05 07:52

15/Mar/08 21:36

3.1

0

Operating System: All
Platform: All

If a BoundedFifoBuffer is serialized and then deserialized the value of the end
attribute is set to the max size of the Buffer which is a fault and causes an
ArrayIndexOutOfBoundException during add(object). In this case the value of end
must be set to 0 in the deserialization.

22/Nov/05 8:43 AM

14 years, 19 weeks ago

18864

No Perforce job exists for this issue.

0

37539

164574

0|i0sj47:

Commons Collections

COLLECTIONS-11

[Collections] LazyList throws IndexOutOfBoundsException when trying to set a value out of list bounds

Bug

Closed

Major

Cannot Reproduce

Unassigned

Heston Fernandes

11/Nov/05 01:05

15/Mar/08 21:35

3.1

0

Operating System: Windows XP
Platform: PC

This was discovered when using struts 1.2.7 with dynamic forms (Tomcat 5.0.24,
jdk 1.4.2). The reset() method in the ActionForm used LazyList.decorate().

if(rooms==null) {
rooms = new ArrayList();
roomPrefs.add("-");
roomPrefs = LazyList.decorate(roomPrefs, factory);
}

However after reset() I get the error below when it tries to initialize the
ArrayList.

IndexOutOfBoundsException -> Index: 1, Size: 1
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.set(ArrayList.java:340)
at
org.apache.commons.collections.list.AbstractListDecorator.set(AbstractListDecorator.java:97)
at
org.apache.commons.beanutils.PropertyUtilsBean.setIndexedProperty(PropertyUtilsBean.java:1417)
at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1016)
at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:811)
at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:298)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:805)
at ....

Possible Solution: For now I've created a class similar to LazyList and have
overridden the set(object, element) method and it has worked.

public Object set(int index, Object element) {
int size = list.size();

// Grow the list
if (index >= size) {
for (int i = size; i <= index; i++) {
list.add(null);
}
}
return list.set(index, element);
}

I'm not sure if I'm using LazyList the right way but thought I'd bring it to
your attention.

Thanks!

11/Nov/05 9:12 AM

14 years, 20 weeks, 4 days ago

18987

No Perforce job exists for this issue.

0

37450

164697

0|i0sjvj:

Commons Collections

COLLECTIONS-101

[collections] CursorableLinkedList iteration broken with previous

Bug

Closed

Major

Fixed

Unassigned

Stephen Colebourne

16/Jul/05 23:14

15/Mar/08 21:36

3.1

0

Operating System: All
Platform: All

With a CursorableLinkedList, if you perform a Next, Next, Previous on an
iterator/cursor, then remove the last object returned by index from the list,
you will leave the cursor in an invalid state.

You should at this point not be able to call remove/set on the iterator, but you
can.

14 years, 37 weeks, 3 days ago

18897

No Perforce job exists for this issue.

0

35766

164607

0|i0sjbj:

Commons Collections

COLLECTIONS-42

[collections] PriorityBuffer iterator does not remove elements properly

Bug

Closed

Major

Cannot Reproduce

Unassigned

Dusan Chromy

02/Mar/05 01:11

15/Mar/08 21:35

3.1

0

Operating System: All
Platform: All

The following code snippet:

System.out.println("----------");
PriorityBuffer s = new PriorityBuffer();
s.add(new Integer(1));
s.add(new Integer(2));
s.add(new Integer(3));

for (Iterator it = s.iterator(); it.hasNext(); s.remove() )
System.out.println(it.next());
System.out.println("----------");

Prints this:
----------
1
3
----------
Element 2 is lost, contrary to javadoc of java.util.Iterator

23/Mar/05 8:06 AM

15 years, 1 week, 6 days ago

18956

No Perforce job exists for this issue.

0

33791

164666

0|i0sjon:

Commons Collections

COLLECTIONS-75

[collections] PriorityBuffer ignores natural order of elements

Bug

Closed

Blocker

Incomplete

Unassigned

Dusan Chromy

01/Mar/05 23:52

16/May/06 12:16

3.1

0

Operating System: All
Platform: All

The following code snippet:
-------------------------------
PriorityBuffer r = new PriorityBuffer();
r.add(new Integer(2));
r.add(new Integer(1));
r.add(new Integer(0));
for (Iterator it = r.iterator(); it.hasNext(); )
System.out.println(":"+it.next());
-------------------------------
Prints this
:0
:2
:1

15 years, 5 weeks ago

18923

No Perforce job exists for this issue.

0

33788

164633

0|i0sjhb:

Commons Collections

COLLECTIONS-124

[collections][PATCH] SetUniqueList breaks when swapping entries

Bug

Closed

Major

Fixed

Unassigned

Tom Dunham

29/Jan/05 04:15

15/Mar/08 21:36

3.1

0

Operating System: All
Platform: PC

If you create a SetUniqueList with two entries a and b:
[a,b]
Then you do:
Object a = l.get(0);
l.set(0, b)
l.add(0, a);
You expect to have swapped the two entries. But you get
[b]
Which seems to be wrong.

04/Feb/05 9:13 AM

15 years, 8 weeks, 4 days ago

18874

No Perforce job exists for this issue.

3

33294

164584

0|i0sj6f:

Commons Collections

COLLECTIONS-36

[collections] MultiHashMap.remove(key, value) always returns a value

Bug

Closed

Major

Fixed

Unassigned

Tad Marko

24/Nov/04 06:01

15/Mar/08 21:35

3.1

0

Operating System: Linux
Platform: PC

According to the documentation, MultiHashMap.remove(key, value) will only return
a value when it removes a value, null if nothing was removed. Instead, it always
returns a value.

04/Jan/05 9:13 AM

15 years, 13 weeks ago

18962

No Perforce job exists for this issue.

0

32366

164672

0|i0sjpz:

Commons Collections

COLLECTIONS-53

[collections] Iterator.remove() in UnboundedFifoBuffer does not work

Bug

Closed

Major

Fixed

Unassigned

Andreas Schlosser

14/Jul/05 18:29

15/Mar/08 21:35

3.1

0

Operating System: All
Platform: All

The implementation of Iterator.remove() in the unbounded fifo buffer is buggy.
It produces an ArrayIndexOutOfBoundExceptions when it needs to swap around the
end of the array to its start.

The code should be:

public void remove() {
if (lastReturnedIndex == -1) {
throw new IllegalStateException();
}

// First element can be removed quickly
if (lastReturnedIndex == head) {
UnboundedFifoBuffer.this.remove();
lastReturnedIndex = -1;
return;
}

// Other elements require us to shift the subsequent elements
/*
* This loop is buggy in the original implementation!
*/
int i = lastReturnedIndex + 1;
while (i != tail) {
buffer[decrement(i)] = buffer[i];
i = increment(i);
}

lastReturnedIndex = -1;
tail = decrement(tail);
buffer[tail] = null;
index = decrement(index);
}

while the original buggy loop is:

// Other elements require us to shift the subsequent elements
int i = lastReturnedIndex + 1;
while (i != tail) {
if (i >= buffer.length) {
buffer[i - 1] = buffer[0];
i = 0;
} else {
buffer[i - 1] = buffer[i];
i++;
}
}

15/Jul/05 7:43 AM

14 years, 37 weeks, 3 days ago

18945

No Perforce job exists for this issue.

0

35733

164655

0|i0sjm7:

Commons Collections

COLLECTIONS-14

[collections] Missing putAll(Map map) in MultiHashMap since 3.1

Bug

Closed

Major

Fixed

Unassigned

Sven Macke

06/Jul/05 23:44

15/Mar/08 21:35

3.1

0

Operating System: Windows 2000
Platform: PC

I just upgraded to version 3.1 and noticed some errors in my application. The
cause is the method putAll(Map map) I used to call on a MultiHashMap to copy to
content of one to another. That method is not defined in MultiHashMap any more,
so HashMap.putAll(Map map) is used. The result of that is a MultiHashMap that
contains ONE value per key and the value itself is a Collection.

Here is some test code I would expect to work, but it fails:

public class MultiHashMapTest extends TestCase
{
public void testIt()
{
MultiMap original = new MultiHashMap();
original.put("key", "object1");
original.put("key", "object2");

MultiMap copy = new MultiHashMap();
copy.putAll(original);

assertEquals(original.values().size(), copy.values().size());
assertTrue(copy.containsValue("object1"));
assertTrue(copy.containsValue("object2"));
}
}

08/Jul/05 9:04 AM

14 years, 37 weeks, 2 days ago

18984

No Perforce job exists for this issue.

0

35631

164694

0|i0sjuv:

Commons Collections

COLLECTIONS-64

[collections] UnboundedFifoBuffer deserialization is broken

Bug

Closed

Major

Fixed

Unassigned

Stephen Colebourne

16/Jul/05 20:24

15/Mar/08 21:35

3.1

0

Operating System: All
Platform: All

The patch should be:

private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
int size = in.readInt();
- buffer = new Object[size];
+ buffer = new Object[size + 1];
for (int i = 0; i < size; i++) {
buffer[i] = in.readObject();
}
head = 0;
tail = size;
}

Setting tail = size - 1; just caused another bug (ie you couldn't get the last
element in the buffer). This is because tail is supposed to point to the next
unused cell in the buffer array. By creating the buffer to be size + 1, tail
will be set to a valid cell within buffer that is empty (but the cell before it
has an element in it), and the class works properly.

Thomas Knych, Jordan Krey & Citigroup Analytics Dev team

14 years, 37 weeks, 3 days ago

18934

No Perforce job exists for this issue.

0

35763

164644

0|i0sjjr:

Commons Collections

COLLECTIONS-107

[collections] AbstractMapBag.BagIterator.remove broken

Bug

Closed

Major

Fixed

Unassigned

Stephen Colebourne

15/Jul/05 08:07

15/Mar/08 21:36

3.1

0

Operating System: All
Platform: All

I can't get in to CVS to see if this is fixed, but there is a bug in
AbstractMapBag in 3.1: BagIterator.remove() does not properly remove the
last instance of a given item; the result is infinite looping. Here is a
patch.

-steve

Steve Clark
ECOS Development Group
steve_clark@fws.gov
(970)226-9291

--- AbstractMapBag.java.orig 2005-07-14 11:14:33.708373173 -0600
+++ AbstractMapBag.java 2005-07-14 11:15:30.566623793 -0600
@@ -221,7 +221,7 @@
throw new IllegalStateException();
}
MutableInteger mut = (MutableInteger) current.getValue();
- if (mut.value > 0) {
+ if (mut.value > 1) {
mut.value--;
parent.size--;
} else {

14 years, 37 weeks, 4 days ago

18891

No Perforce job exists for this issue.

0

35747

164601

0|i0sja7:

Commons Collections

COLLECTIONS-104

[collections] Only last element is removeable when CircularFifoBuffer is full

Bug

Closed

Major

Fixed

Unassigned

Amir Tahvildaran

13/Jan/05 03:30

15/Mar/08 21:36

3.1

0

Operating System: Linux
Platform: PC

If the circular fifo buffer is full and you remove an item, that is not the last
one, it breaks.

code example:

import java.io.*;
import org.apache.commons.collections.buffer.*;

class Stub {
public static void main(String[] args) {
CircularFifoBuffer fifo = new CircularFifoBuffer(5);
System.out.println(fifo);

fifo.add(new String("1"));
System.out.println(fifo);

fifo.add(new String("2"));
System.out.println(fifo);

fifo.add(new String("3"));
System.out.println(fifo);

fifo.add(new String("4"));
System.out.println(fifo);

System.out.println("adding 5");
fifo.add(new String("5"));
System.out.println(fifo);

String six = new String("6");
System.out.println("adding 6");
fifo.add(six);
System.out.println(fifo);

/* uncomment the following block to avoid problem
System.out.println("fifo.isFull?:"+fifo.isFull());
System.out.println("removing 6");
fifo.remove(new String("6"));
System.out.println(fifo);
*/

System.out.println("fifo.isFull?:"+fifo.isFull());

System.out.println("removing 3");
fifo.remove(new String("3"));
System.out.println(fifo);

System.out.println("removing 4");
fifo.remove(new String("4"));
System.out.println(fifo);

System.out.println("clearing");
fifo.clear();
System.out.println("removing 4");
fifo.remove(new String("4"));
System.out.println(fifo);

}
}

==============

output busted:

[]
[1]
[1, 2]
[1, 2, 3]
[1, 2, 3, 4]
adding 5
[1, 2, 3, 4, 5]
adding 6
[2, 3, 4, 5, 6]
fifo.isFull?:true
removing 3
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at
org.apache.commons.collections.buffer.BoundedFifoBuffer$1.remove(BoundedFifoBuffer.java:347)
at java.util.AbstractCollection.remove(AbstractCollection.java:255)
at Stub.main(Stub.java:40)

14/Jan/05 11:16 PM

14 years, 7 weeks, 6 days ago

18894

No Perforce job exists for this issue.

0

33071

164604

0|i0sjav:

Commons Collections

COLLECTIONS-85

ReferenceMap clears bindings too early

Bug

Closed

Major

Invalid

Unassigned

Eric Bodden

04/Mar/06 15:58

07/Aug/06 21:08

3.1

Map

0

Operating System: Windows XP
Platform: Other

Hello. This week I had to debug some small example program we are currently
working on and it really took me a long time to find the actual problem because
apprently there seems to be a bug in the implementation of ReferenceMap, which
was really very unexpected for me. To me this seems very critical because I
reckon that the ReferenceMap is in wide use. Hence I am describing my findings
in detail.

The code is AspectJ code, but I also provide the bytecode. The puspose of the
code is to detect the so-called "lock order reversal pattern", a temporal event
pattern which gives indication of potentially unsafe locking. It tries to
detect patterns where a thread t1 tries to acquire locks in the order l1 l2 and
another thread t2 tries to do so in the order r2 r1.

When you compile the attached code with the AspectBench compiler (www.
aspectbench.org) and then execute "java LORTest", depending on the map
implementation you choose, one of the following traces is produced:

- "log": your commons impl. (Reference identity map with weak key and values)
- "log_jre": the JRE impl. (hash map with weak keys, no identity map, but does
not matter since the keys are threads, which do not implement equals(...))

(Both logs are also in the tarball.)

In log_jre you see that the LOR is detected (at the bottom). That works as
follows: Whenever a lock is taken, the relationship (thread,lock) is put into a
first (weak) map (see logging points "Xa"). Also, for all such relations which
are contained already, we put a reference to a pair (thread,(lock1,lock2)) into
a second map (logging points "Xb"). This represents the information "thread"
took first "lock1" then "lock2".

As "log" shows, the weak map by commons is looses all the sudden some bindings.
(Compare to log_jre.) This seems really buggy, since subsequent logging output
shows that the threads and locked resources still exist!

For me this is fully deterministically reproducable. I am using Windows XP with
this JRE:

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

You can compile the code (using the AspectBench compiler) with "compile.bat" or
you can just run it with "run.bat", if you like.

26/Mar/06 3:20 AM

13 years, 34 weeks, 2 days ago

18913

No Perforce job exists for this issue.

1

38853

164623

0|i0sjf3:

Commons Collections

COLLECTIONS-51

[collections] LRUMap loses values when resizing.

Bug

Closed

Critical

Incomplete

Unassigned

Dave Dandeneau

23/Feb/06 01:15

15/Mar/08 21:35

3.1

0

Operating System: Windows XP
Platform: PC

I am using the LRUMap and I have noticed that when it resizes the Map it loses
the values that were in it previously. I noticed this when it was resizing my
map from size of 2 to size of 4.

23/Feb/06 1:25 AM

14 years, 5 weeks, 6 days ago

18947

No Perforce job exists for this issue.

0

38753

164657

0|i0sjmn:

Commons Collections

COLLECTIONS-67

[collections] PriorityBuffer does not implement Serializable

Bug

Closed

Minor

Fixed

Unassigned

Steve Phelps

12/Aug/05 23:42

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: Other

The class org.apache.commons.collections.buffer.PriorityBuffer does not
implement java.io.Serializable

08/Oct/05 9:51 PM

14 years, 25 weeks, 3 days ago

18931

No Perforce job exists for this issue.

2

36163

164641

0|i0sjj3:

Commons Collections

COLLECTIONS-48

[collections] TransformedMap putAll(empty map) causes IllegalArgumentException

Bug

Closed

Major

Fixed

Unassigned

Marc Lottman

30/Apr/05 06:33

15/Mar/08 21:35

3.1

0

Operating System: Windows XP
Platform: PC

If you create a TransformedMap, and then call map.putAll with an empty map as
an argument, an IllegalArgumentException is thrown. putAll should be able to
handle empty maps without erroring. The error occurs regardless of whether
the decorated map has any contents. The implementation of the Transformers
attached does not matter. I am using Java 1.4.2_07.

Example code:
Map map = TransformedMap.decorate(
new HashMap(),
TransformerUtils.nopTransformer(),
TransformerUtils.nopTransformer());

map.putAll(new HashMap()); // This causes IllegalArgumentException!

Fails with the following error:

java.lang.IllegalArgumentException: Initial capacity must be greater than 0
at org.apache.commons.collections.map.AbstractHashedMap.<init>
(AbstractHashedMap.java:142)
at org.apache.commons.collections.map.AbstractHashedMap.<init>
(AbstractHashedMap.java:127)
at org.apache.commons.collections.map.AbstractLinkedMap.<init>
(AbstractLinkedMap.java:95)
at org.apache.commons.collections.map.LinkedMap.<init>
(LinkedMap.java:78)
at org.apache.commons.collections.map.TransformedMap.transformMap
(TransformedMap.java:153)
at org.apache.commons.collections.map.TransformedMap.putAll
(TransformedMap.java:190)
at net.carefx.contextagent.plugin.ldapuser.PluginTest.main
(PluginTest.java:71)

08/May/05 2:14 AM

14 years, 7 weeks, 5 days ago

18950

No Perforce job exists for this issue.

0

34686

164660

0|i0sjnb:

Commons Collections

COLLECTIONS-122

[collections] CircularFifoBuffer not really Serializable

Bug

Closed

Major

Fixed

Unassigned

Kalle Gustafsson

27/Sep/04 14:24

15/Mar/08 21:36

3.1

3.2

0

Operating System: Solaris
Platform: Sun

Create a CircularFifoBuffer of size N. Serialize and deserialize a couple of
times. When adding element N+1, an error occurs. (OutOfMemoryError in our
testing environment, ArrayIndexOutOfBounds when running the code snippet.)

The error can be reproduced by running the following code snippet in a scrapbook
page in WebSphere Studio 5.1.2 (default JRE) on Windows XP (The error occurs at
the third add operation):

org.apache.commons.collections.buffer.CircularFifoBuffer b = new
org.apache.commons.collections.buffer.CircularFifoBuffer(2);

b.add("a");

java.io.ByteArrayOutputStream bos = new java.io.ByteArrayOutputStream();
new java.io.ObjectOutputStream(bos).writeObject(b);

org.apache.commons.collections.buffer.CircularFifoBuffer b2 =
(org.apache.commons.collections.buffer.CircularFifoBuffer) new
java.io.ObjectInputStream(new
java.io.ByteArrayInputStream(bos.toByteArray())).readObject();

b2.add("b");

bos = new java.io.ByteArrayOutputStream();
new java.io.ObjectOutputStream(bos).writeObject(b2);

b = (org.apache.commons.collections.buffer.CircularFifoBuffer) new
java.io.ObjectInputStream(new
java.io.ByteArrayInputStream(bos.toByteArray())).readObject();

b.add("c");

bos = new java.io.ByteArrayOutputStream();
new java.io.ObjectOutputStream(bos).writeObject(b);

b2 = (org.apache.commons.collections.buffer.CircularFifoBuffer) new
java.io.ObjectInputStream(new
java.io.ByteArrayInputStream(bos.toByteArray())).readObject();

17/Oct/04 5:26 AM

14 years, 19 weeks ago

18876

No Perforce job exists for this issue.

0

31433

164586

0|i0sj6v:

Commons Collections

COLLECTIONS-59

[collections] FastArrayList iterator method throwing ConcurrentModificationException in 'fast' mode

Bug

Closed

Major

Fixed

Unassigned

Robert Cooke

17/Jun/04 06:55

15/Mar/08 21:35

3.1

3.2

0

Operating System: Linux
Platform: All

Please review the below code, I was under the impression that this not throw an
exception.

Thanks,

Rob Cooke.

----------------------------

import org.apache.commons.collections.FastArrayList;

import java.util.Iterator;

public class Test2 extends Thread{

public static void main(String argv[]) throws Exception{

FastArrayList array=new FastArrayList();

array.add("this");

array.add("is");

array.add("a");

new Test2(array).start();

array.setFast(true);

Thread.sleep(2000);

array.add("test");

}

protected FastArrayList array;

public Test2(FastArrayList array){

this.array=array;

}

public void run(){

for(Iterator i=array.iterator();i.hasNext();){

try{Thread.sleep(1000);}catch(Exception e){}

System.out.println(i.next());

}

}

}

23/Jun/04 4:19 AM

15 years, 40 weeks, 5 days ago

18939

No Perforce job exists for this issue.

0

29625

164649

0|i0sjkv:

Commons Collections

COLLECTIONS-84

TreeList with inproved iterator() and listIterator() implementation

Bug

Closed

Major

Fixed

Unassigned

Joerg Schmuecker

12/May/04 23:08

15/Mar/08 21:36

3.1

0

Operating System: other
Platform: Other

Added references to next and and prev using a flag. This is called Faedelung in
German :-)

13/May/04 6:19 AM

15 years, 46 weeks, 5 days ago

18914

No Perforce job exists for this issue.

2

28930

164624

0|i0sjfb:

Commons Collections

COLLECTIONS-65

[collections] Collection inside Abstract[AnyCollection]Decorator really needed to be transient?

Bug

Closed

Major

Cannot Reproduce

Unassigned

Xavier Dury

07/Sep/04 21:42

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: Other

Hi,

I would like to know if there was any good reason for all abstract decorator
classes (like AbstractMapDecorator) to have their decorated collection (map)
transient? It doesn't help when trying to store decorated collections with
XStream for example... Maybe there's a -really- good reason but I can't see it.

thanks a lot and go on with the good work! :)

Xavier.

08/Sep/04 4:01 AM

15 years, 29 weeks, 6 days ago

18933

No Perforce job exists for this issue.

0

31091

164643

0|i0sjjj:

Commons Collections

COLLECTIONS-26

CompositeSet always supports remove operation

Bug

Closed

Major

Fixed

Unassigned

Koji Sekiguchi

07/Sep/04 13:38

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: Other

CompositeSet javadoc says "If no strategy is provided then add and remove are
unsupported." but the class always supports remove operation. The documentation
should be revised as "If no strategy is provided then add is unsupported."

regards,

Koji

23/Sep/04 6:41 AM

15 years, 27 weeks, 5 days ago

18972

No Perforce job exists for this issue.

0

31082

164682

0|i0sjs7:

Commons Collections

COLLECTIONS-37

[collections] The commons-collections 'binary distro' on the Jakarta Website is actually the 'source distro'

Bug

Closed

Major

Won't Fix

Unassigned

David Tonhofer

23/Aug/04 23:22

15/Mar/08 21:35

3.1

0

Operating System: Linux
Platform: PC

The subject says it all

24/Aug/04 3:00 AM

15 years, 32 weeks ago

18961

No Perforce job exists for this issue.

0

30806

164671

0|i0sjpr:

Commons Collections

COLLECTIONS-39

[collections] ExtendedProperties should not just allow NPEs

Bug

Closed

Minor

Fixed

Unassigned

john tal

06/Aug/04 01:23

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: Other

Its really an annoyance because I frequently have my debugger stop on
NullPointerException.

ExtendedProperties.readProperty

Change from
String line = readLine().trim();
to
String line = readLine();
if(line != null) line = line.trim(); else return null;

Also in ExtendedProperties.load

while (true) {
String line = reader.readProperty();
if(line == null)
return;
int equalSign = line.indexOf('=');

23/Sep/04 6:37 AM

15 years, 27 weeks, 5 days ago

18959

No Perforce job exists for this issue.

0

30497

164669

0|i0sjpb:

Commons Collections

COLLECTIONS-46

[collections] CollectionUtils.transformedCollection(c,t) doesn't transform the elements of c

Bug

Closed

Major

Won't Fix

Unassigned

Gunnar Zarncke

30/Jul/04 19:26

15/Mar/08 21:35

3.1

0

Operating System: other
Platform: All

CollectionUtils.transformedCollection(c,t) doesn't transform the elements of c
as documented in the API.
The implementation passes this collection to
TransformedCollection.decorate(collection, transformer)
and further to
new TransformedCollection(coll, transformer);
where super(c) simply stored it WITHOUT conversion.

04/Aug/04 12:11 AM

15 years, 34 weeks, 6 days ago

18952

No Perforce job exists for this issue.

1

30408

164662

0|i0sjnr:

Commons Collections

COLLECTIONS-587

commons-collections-3.2.2 does not compile under docker fedora21

Bug

Resolved

Major

Won't Fix

Unassigned

Marc Pawlowsky

26/Apr/16 16:36

18/Mar/20 02:41

26/Apr/16 21:10

3.2

0

1

docker, fedora21

In a clean environment using docker, compile errors

$cat Dockerfile
FROM fedora:21
RUN yum update -y
RUN yum install -y java-1.8.0-openjdk unzip maven wget
RUN wget http://apache.mirror.rafal.ca//commons/collections/source/commons-collections-3.2.2-src.zip
RUN unzip commons-collections-3.2.2-src.zip
RUN cd commons-collections-3.2.2-src && mvn initialize
RUN cd commons-collections-3.2.2-src && mvn install
RUN chmod -R 755 /root
CMD /bin/bash
$docker build .
<snip/>
Downloaded: http://repo.maven.apache.org/maven2/commons-[INFO] Changes detected - recompiling the module!
[INFO] Compiling 273 source files to /commons-collections-3.2.2-src/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiHashMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiMap clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiValueMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiKeyMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
return type java.lang.Object is not compatible with boolean
[INFO] 4 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.104 s
[INFO] Finished at: 2016-04-26T12:35:24-04:00
[INFO] Final Memory: 19M/203M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project commons-collections: Compilation failure: Compilation failure:
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiHashMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/MultiMap.java:[69,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.MultiMap clashes with remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiValueMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] /commons-collections-3.2.2-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19] remove(java.lang.Object,java.lang.Object) in org.apache.commons.collections.map.MultiKeyMap cannot implement remove(java.lang.Object,java.lang.Object) in java.util.Map
[ERROR] return type java.lang.Object is not compatible with boolean
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
The command '/bin/sh -c cd commons-collections-3.2.2-src && mvn install' returned a non-zero code: 1

26/Apr/16 6:09 PM

3 years, 47 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2wrdr:

Commons Collections

COLLECTIONS-359

A ∩ B != B ∩ A when duplicates are present in a list

Bug

Closed

Major

Fixed

Unassigned

Mark Shead

05/Jul/10 14:58

09/Nov/14 14:31

28/Feb/13 19:37

3.2

4.0-alpha1, 4.0

Collection

0

1

When duplicates are present in a list, ListUtils.intersection doesn't behave as expected. The intersection of two lists should give the same result regardless of which list comes first. ListUtils.intersection(A,B) should equal ListUtils.intersection(B,A). This is not the case when the list contains duplicates.

Right now:
[a, b] ∩ [a, a, b, b] = [a, a, b, b]
and
[a, a, b, b] ∩ [a, b] = [a, b]

Expected behavior:

[a, a, b, b] ∩ [a, b] = [a, b]
[a, b] ∩ [a, a, b, b] = [a, b]

Code demonstrating the problem.

List A = new ArrayList();
List B = new ArrayList();
A.add("a");
A.add("b");
B.add("a");
B.add("a");
B.add("b");
B.add("b");
System.out.println("List A: " + A);
System.out.println("List B: " + B);
System.out.println("A ∩ B = " + ListUtils.intersection(A,B));
System.out.println("B ∩ A = " +ListUtils.intersection(B,A));

output:

List A: [a, b]
List B: [a, a, b, b]
A ∩ B = [a, a, b, b]
B ∩ A = [a, b]

18/Jul/10 7:43 AM

9 years, 36 weeks, 2 days ago

18644

No Perforce job exists for this issue.

1

164388

0|i0shyv:

Commons Collections

COLLECTIONS-360

FilterListIterator#hasNext throws exception (associate with JUnit tests)

Bug

Closed

Major

Fixed

Jochen Wiedmann

Sai Zhang

23/Aug/10 19:29

09/Nov/14 14:31

01/Mar/11 22:17

3.2

4.0-alpha1, 4.0

0

1

ubuntu

Hi,

I found the some of the iterator classes does not fulfill the iterator specification of JDK.

e.g. hasNext() should never throw exception.

Here is an automatically generated junit test (I am now writing a tool)

{code:java}
public void test233() throws Throwable {
java.lang.Integer var6 = new java.lang.Integer(0);
org.apache.commons.collections.list.GrowthList var7 = new org.apache.commons.collections.list.GrowthList(var6);
org.apache.commons.collections.Predicate var9 = org.apache.commons.collections.PredicateUtils.anyPredicate((java.util.Collection)var7);
java.lang.Long var10 = new java.lang.Long(10L);
org.apache.commons.collections.iterators.FilterListIterator var13 = new org.apache.commons.collections.iterators.FilterListIterator(var9);
//this line throws exception!
var13.hasNext();
}
{code}
could you please check it to confirm whether it is bug or I misunderstand the specification of apache common collections?

thanks,

13/Dec/10 8:56 AM

9 years, 4 weeks ago

18643

No Perforce job exists for this issue.

1

164387

0|i0shyn:

Commons Collections

COLLECTIONS-357

CollectionUtils.removeAll invokes wrong Listutils method

Bug

Closed

Critical

Duplicate

Unassigned

Fabian Lange

24/Jun/10 20:03

09/Nov/14 14:31

28/Feb/13 19:25

3.2

4.0-alpha1, 4.0

Collection

0

COLLECTIONS-371, COLLECTIONS-386, COLLECTIONS-219, COLLECTIONS-358, COLLECTIONS-369, COLLECTIONS-376

{code}
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
{code}

18/Jul/10 7:40 AM

9 years, 36 weeks, 2 days ago

18646

No Perforce job exists for this issue.

0

164390

0|i0shzb:

Commons Collections

COLLECTIONS-331

CollatingIterator NPE when Comparator is null

Bug

Closed

Minor

Fixed

Jochen Wiedmann

Michael Krkoska

24/Jun/09 14:32

09/Nov/14 14:31

08/Mar/11 22:33

3.2

4.0-alpha1, 4.0

Iterator

0

1

300

0%

Run the attached Test against commons-collections-3.2.1. While the JavaDoc for CollatingIterator claims

{{@param comp the comparator to use to sort, or null to use natural sort order}}

the test fails, because the comparator is null.

Fixing this requires a change in {{org.apache.commons.collections.iterators.CollatingIterator.least()}}:

{code}
if (comparator.compare(curObject,leastObject) < 0) { ...
{code}

could be replaced with

{code}
int c = comparator==null?((Comparable)curObject).compareTo(leastObject):comparator.compare(curObject,leastObject);
if (c < 0) { ...
{code}

The workaround is to provide a comparator, of course.

0%

300

26/Mar/10 6:35 AM

7 years, 34 weeks, 5 days ago

18672

No Perforce job exists for this issue.

2

164410

0|i0si3r:

Commons Collections

COLLECTIONS-373

Bug in class#ListOrderedSet with reproducible JUnit test

Bug

Closed

Major

Invalid

Unassigned

Sai Zhang

03/Apr/11 07:43

18/Mar/20 02:40

27/Nov/15 21:47

23/Jan/13 17:05

3.2

0

jdk 1.6.x

Hi all:

I am writing an automated bug finding tool, and using
Apache Commons Collections as an experimental subject
for evaluation.

The tool creates executable JUnit tests as well as
explanatory code comments. I attached one bug-revealing
test as follows. Could you please kindly check it, to
see if it is a real bug or not?

Also, it would be tremendous helpful if you could give
some feedback and suggestion on the generated code comments?
From the perspective of developers who are relatively familiar
with the code,
is the automatically-inferred comment useful in understanding
the generated test? is the comment helpful in bug fixing?

Your suggestion will help us improve the tool.

Please see attachment for the failed test. A little explaination
on the generated code comments in the failed test

//explaination:
//Test passes if var53 is: (java.lang.Boolean)false ===> means:
// test passes if var52 is not added to var28 (only in that case, var53 is false)
boolean var53 = var28.add((java.lang.Object)var52);

patch

23/Jan/13 5:04 PM

7 years, 8 weeks, 6 days ago

18630

No Perforce job exists for this issue.

1

90355

0|i0ftd3:

Commons Collections

COLLECTIONS-374

Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test

Bug

Closed

Major

Won't Fix

Unassigned

Sai Zhang

03/Apr/11 08:02

18/Mar/20 02:41

27/Nov/15 21:47

18/Apr/13 19:09

3.2

0

jdk 1.6.0

Hi all:

(as in the previous post)

I am writing an automated bug finding tool, and using
Apache Commons Collections as an experimental subject
for evaluation.

The tool creates executable JUnit tests as well as
explanatory code comments. I attached one bug-revealing
test as follows. Could you please kindly check it, to
see if it is a real bug or not?

Also, it would be tremendous helpful if you could give
some feedback and suggestion on the generated code comments?
From the perspective of developers who are relatively familiar
with the code,
is the automatically-inferred comment useful in understanding
the generated test? is the comment helpful in bug fixing?

Your suggestion will help us improve the tool.

Please see attachment for the failed test.

The comment appears in the form of:
//Tests pass if .... (it gives some small change to the test which can make the failed test pass)

03/Apr/11 10:22 AM

6 years, 48 weeks, 5 days ago

18629

No Perforce job exists for this issue.

1

90354

0|i0ftcv:

Commons Collections

COLLECTIONS-355

class cast exception in common collection-3.2 jar

Bug

Closed

Major

Invalid

Unassigned

maneesh

26/May/10 13:18

19/Jun/10 19:37

3.2

Map

0

Unix, jdk 1.5.0.06

Recently I have upgraded common collection jar to 3.2 version. After that I got a class cast exception in the following code java code
String checkedInStation = (String)(((HashMap)lstQueuedPsgrs.get(startIndex))
.get("PSGRCHECKEDINSTATION"));

The exception detail as below

java.lang.ClassCastException: org.apache.commons.collections.map.ListOrderedMap
at sun.reflect.GeneratedMethodAccessor279.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:287)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:181)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation

26/May/10 1:25 PM

9 years, 40 weeks, 3 days ago

18648

No Perforce job exists for this issue.

0

164391

0|i0shzj:

Commons Collections

COLLECTIONS-371

BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection)

Bug

Closed

Critical

Duplicate

Unassigned

li gui

31/Jan/11 19:17

01/Feb/11 07:19

3.2

Collection

0

COLLECTIONS-357

line: 1121
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove); //<<<<<-------- here absolutely wrong!

}

9 years, 8 weeks, 1 day ago

18632

No Perforce job exists for this issue.

0

164379

0|i0shwv:

Commons Collections

COLLECTIONS-369

CollectionUtils#removeAll is broken

Bug

Closed

Major

Duplicate

Unassigned

Michael Harris

06/Jan/11 05:52

06/Jan/11 07:29

3.2

0

COLLECTIONS-357

method calls into ListUtils#retainAll instead of ListUtils#removeAll. Should be easy fix for someone with commit rights.

9 years, 11 weeks, 5 days ago

18634

No Perforce job exists for this issue.

0

164380

0|i0shx3:

Commons Collections

COLLECTIONS-363

TransformedMap is Serializable but its superclass doesn't define an accessible void constructor

Bug

Closed

Major

Fixed

Unassigned

Sebb

16/Oct/10 01:39

09/Nov/14 14:31

20/Dec/10 19:25

3.2

4.0-alpha1, 4.0

Map

0

1

TransformedMap is Serializable but its superclass doesn't define an accessible void constructor.
For example, the following test fails:

{code}
public void testSerialisation() throws Exception {
TransformedMap<String, String, String, String> map = TransformedMap.decorate(
new HashMap<String, String>(), NOPTransformer.<String> getInstance(), NOPTransformer.<String> getInstance());
ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bytes);
out.writeObject(map); // fails with java.io.InvalidClassException: org.apache.commons.collections.splitmap.TransformedMap; no valid constructor
out.close();
}
{code}

13/Dec/10 7:50 AM

9 years, 14 weeks, 1 day ago

18640

No Perforce job exists for this issue.

4

164385

0|i0shy7:

Commons Collections

COLLECTIONS-377

CollatingIterator throws NullPointerException when constructor is given null (or no) Comparator

Bug

Closed

Minor

Duplicate

Unassigned

Ryan Hochstetler

18/Jul/11 19:51

18/Mar/20 02:41

09/Nov/14 14:31

03/Jun/12 11:19

3.2

4.0-alpha1, 4.0

Iterator

0

1

Java 1.6.0_26

CollatingIterator's javadoc (http://commons.apache.org/collections/api-release/index.html) states that natural sort ordering will be used when null is passed as the Comparator argument to any of the constructors accepting one (and for the nullary constructor). The following stack is thrown from the subsequent unit test. The implementation of least() does not appear to account for the natural sort order case.

java.lang.NullPointerException
at org.apache.commons.collections.iterators.CollatingIterator.least(CollatingIterator.java:334)
at org.apache.commons.collections.iterators.CollatingIterator.next(CollatingIterator.java:230)
at mil.af.statistics.jutl.collection.MutableDataSeriesTest...

@SuppressWarnings("unchecked")
@Test
public void testCollatingIteratorNaturalOrdering() throws Exception
{
Integer[] expected =
{ Integer.valueOf(1), Integer.valueOf(2), Integer.valueOf(3), Integer.valueOf(4), Integer.valueOf(5),
Integer.valueOf(6) };
List<Integer> evens = Arrays.asList(new Integer[]
{ Integer.valueOf(2), Integer.valueOf(4), Integer.valueOf(6) });
List<Integer> odds = Arrays.asList(new Integer[]
{ Integer.valueOf(1), Integer.valueOf(3), Integer.valueOf(5) });

Iterator<Integer> collatingIter = new CollatingIterator(null, evens.iterator(), odds.iterator());

for (Integer expectedInt : expected)
{
assertTrue(collatingIter.hasNext());
assertEquals(expectedInt, collatingIter.next());
}
}

Workaround: provide a Comparator that implements the natural ordering contract.

20/Oct/11 12:00 PM

7 years, 42 weeks, 2 days ago

18626

No Perforce job exists for this issue.

0

164377

0|i0shwf:

Commons Collections

COLLECTIONS-304

SetUniqueList set method use corrupts uniqness

Bug

Closed

Major

Fixed

Unassigned

Rafał Figas

05/Sep/08 10:43

08/Nov/15 21:27

28/Feb/13 19:38

3.2

3.2.2, 4.0-alpha1, 4.0

0

JDK 1.6/Windows/Eclipse Ganymede

When set method is used to put element (Strawberry) on list, then it is possible to add the same element (Strawberry) with add method. Also you cannot add element (Lemon) that has been once removed with set method. Reproduction code below:

List<String> list = new LinkedList<String>();
SetUniqueList decoratedList = SetUniqueList.decorate(list);

decoratedList.add("Apple");
decoratedList.add("Lemon");
decoratedList.add("Orange");

System.out.println(decoratedList.toString());

decoratedList.set(1, "Strawberry");

System.out.println(decoratedList.toString());

decoratedList.add(1, "Strawberry");

System.out.println(decoratedList.toString());

decoratedList.add(1, "Lemon");

System.out.println(decoratedList.toString());

04/Nov/08 12:23 AM

11 years, 20 weeks, 6 days ago

18697

No Perforce job exists for this issue.

2

164429

0|i0si7z:

Commons Collections

COLLECTIONS-348

Javadoc: incorrect behavior explained for XXXUtils.transformedXXX

Bug

Closed

Major

Fixed

Unassigned

Paul Benedict

20/Dec/09 03:58

09/Nov/14 14:31

15/Oct/10 19:39

3.2

4.0-alpha1, 4.0

Bag, Collection, List, Map, Set

0

COLLECTIONS-288

As a sequel to COLLECTIONS-288, any utility method that "transformed" needs to document that the incoming collection is not immediately transformed -- future additions are.

Candidate methods:
* BagUtils.transformedBag
* BagUtils.transformedSortedBag
* CollectionUtils.transform
* CollectionUtils.transformedCollection
* ListUtils.transformedList *done*
* MapUtils.transformedMap
* MapUtils.transformedSortedMap
* SetUtils.transformedSet
* SetUtils.transformedSortedSet

15/Oct/10 7:39 PM

9 years, 23 weeks, 4 days ago

18655

No Perforce job exists for this issue.

0

164396

0|i0si0n:

Commons Collections

COLLECTIONS-346

SetUniqueList.decorate throws exceptions that is not documented

Bug

Closed

Major

Won't Fix

Unassigned

Jimmy Shi

24/Nov/09 23:18

19/Jun/10 19:41

3.2

List

0

public static void main(String[] args) {
List<String> testList=Arrays.asList("a","b","c","a","b","c","e");
SetUniqueList decoratedList = SetUniqueList.decorate(testList);
System.out.println(decoratedList);
}

throws below exception:
Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractList.remove(AbstractList.java:172)
at java.util.AbstractList$Itr.remove(AbstractList.java:437)
at java.util.AbstractList.removeRange(AbstractList.java:662)
at java.util.AbstractList.clear(AbstractList.java:258)
at org.apache.commons.collections.list.SetUniqueList.decorate(SetUniqueList.java:80)

caused by the list to decorate is unmodifiable.

02/Feb/10 12:13 AM

9 years, 40 weeks, 3 days ago

18657

No Perforce job exists for this issue.

0

164397

0|i0si0v:

Commons Collections

COLLECTIONS-310

Modifications of a SetUniqueList.subList() invalidate the parent list

Bug

Closed

Minor

Fixed

Unassigned

Christian Semrau

10/Jan/09 13:58

18/Mar/20 03:00

09/Nov/14 14:31

27/Apr/13 11:57

3.2, Nightly Builds

4.0-alpha1, 4.0

List

0

1

COLLECTIONS-444

The List returned by SetUniqueList.subList() is again a SetUniqueList. The contract for List.subList() says that the returned list supports all the operations of the parent list, and it is backed by the parent list.

We have a SetUniqueList uniqueList equal to {"Hello", "World"}. We get a subList containing the last element. Now we add the element "Hello", contained in the uniqueList but not in the subList, to the subList.

What should happen?

Should the subList behave like a SetUniqueList and add the element - meaning that it changes position in the uniqueList because at the old place it gets removed, so now uniqueList equals {"World", "Hello"} (which fails)?
Or should the element not be added, because it is already contained in the parent list, thereby violating the SetUniqueList-ness of the subList (which fails)?
I prefer the former behaviour, because modifications should only be made through the subList and not through the parent list (as explained in List.subList()).

What should happen if we replace (using set) the subList element "World" with "Hello" instead of adding an element?

The subList should contain only "Hello", and for the parent list, the old element 0 (now a duplicate of the just set element 1) should be removed (which fails).

And of course the parent list should know what happens to it (specifically, its uniqueness Set) (which fails in the current snapshot).

public void testSubListAddNew() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add("Hello");
uniqueList.add("World");
List subList = uniqueList.subList(1, 2);

subList.add("Goodbye");

List expectedSubList = Arrays.asList(new Object[] { "World", "Goodbye" });
List expectedParentList = Arrays.asList(new Object[] { "Hello", "World", "Goodbye" });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList);
assertTrue(uniqueList.contains("Goodbye")); // fails
}

public void testSubListAddDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add("Hello");
uniqueList.add("World");
List subList = uniqueList.subList(1, 2);

subList.add("Hello");

List expectedSubList = Arrays.asList(new Object[] { "World", "Hello" });
List expectedParentList = Arrays.asList(new Object[] { "World", "Hello" });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}

public void testSubListSetDuplicate() {
List uniqueList = SetUniqueList.decorate(new ArrayList());
uniqueList.add("Hello");
uniqueList.add("World");
List subList = uniqueList.subList(1, 2);

subList.set(0, "Hello");

List expectedSubList = Arrays.asList(new Object[] { "Hello" });
List expectedParentList = Arrays.asList(new Object[] { "Hello" });
assertEquals(expectedSubList, subList);
assertEquals(expectedParentList, uniqueList); // fails
}

26/Jan/13 4:30 PM

6 years, 47 weeks, 3 days ago

18691

No Perforce job exists for this issue.

5

90373

0|i0fth3:

Commons Collections

COLLECTIONS-308

CollectionUtils.transform fails when collection is HashMap$Values

Bug

Closed

Minor

Won't Fix

Unassigned

Lluís Martínez

23/Dec/08 23:32

24/Dec/08 14:19

3.2

Collection

0

Ubuntu

I'm trying to apply a transformation to all values in a map :

Collection values = map.values();
CollectionUtils.transform(values, transformer);

Gives a java.lang.UnsupportedOperationException in CollectionUtils line 439.

According to Javadoc the method values of Hashmap "does not support the add or addAll operations.".

24/Dec/08 12:47 AM

11 years, 13 weeks, 6 days ago

18693

No Perforce job exists for this issue.

0

164426

0|i0si7b:

Commons Collections

COLLECTIONS-376

CollectionUtils.removeAll return retainAll - 3.2.1

Bug

Closed

Major

Duplicate

Unassigned

Patrick Sauts

01/Jul/11 17:15

18/Mar/20 02:41

01/Jul/11 23:03

3.2

Collection

0

COLLECTIONS-357

The code of removeAll method isn't correct

ligne 1121 of CollectionUtils
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}

01/Jul/11 11:03 PM

8 years, 38 weeks, 4 days ago

18627

No Perforce job exists for this issue.

0

164378

0|i0shwn:

Commons Collections

COLLECTIONS-294

Fix case-insensitive string handling

Bug

Closed

Major

Fixed

Unassigned

Benjamin Bentmann

25/Apr/08 14:31

07/Nov/15 21:17

28/Feb/13 19:38

3.2

3.2.2, 4.0-alpha1, 4.0

Map

0

For example, the behavior of the {{CaseInsensitiveMap}} is currently platform-dependent, please see [Common Bug #3|http://www.nabble.com/Re%3A-Common-Bugs-p14931921s177.html] for details.

10/May/08 10:46 PM

11 years, 6 weeks, 1 day ago

18707

No Perforce job exists for this issue.

2

164438

0|i0si9z:

Commons Collections

COLLECTIONS-279

LRUMap: moveToMRU is not invoked for new entry

Bug

Closed

Blocker

Duplicate

Unassigned

Andrey Andreev

28/Nov/07 07:12

27/Nov/15 21:47

28/Feb/13 19:29

3.2

Map

2

1

COLLECTIONS-262

@Test
public void testFirst() {
LRUMap map = new LRUMap();

String key = "key1";
String value = "value1";

map.put(key, value);
Assert.assertEquals(map.get(key), value);
Assert.assertEquals(map.get(map.firstKey()), value);

key = "key2";
value = "value2";
map.put(key, value);
// here it fails
Assert.assertEquals(map.get(map.firstKey()), value);
}

28/Dec/07 1:29 PM

12 years, 2 weeks, 3 days ago

18721

No Perforce job exists for this issue.

1

164449

0|i0sicf:

Commons Collections

COLLECTIONS-278

put() and putAll() don't update the getKeys() map

Bug

Closed

Major

Fixed

Unassigned

Henning Schmiedehausen

13/Nov/07 21:24

27/Nov/15 21:11

28/Feb/13 20:05

3.2

0

COLLECTIONS-351

If you use the put() or putAll() methods of the ExtendedProperties class, it will not update the contents of the internal keysAsListed map which in turn will return a different list of keys using the getKeys() method than the keySet() method does.

The attached patchs fix this behaviour and add test cases.

03/Jan/08 3:49 AM

6 years, 48 weeks, 1 day ago

18722

No Perforce job exists for this issue.

4

164450

0|i0sicn:

Commons Collections

COLLECTIONS-271

org.apache.commons.collections.ExtendedProperties#combine don't import string properly

Bug

Closed

Major

Fixed

Unassigned

Alexander Borovsky

16/Oct/07 12:40

27/Nov/15 21:11

28/Feb/13 19:56

3.2

Collection

1

COLLECTIONS-351

When we set property with escaped characters, after combine propertySets we got them unescaped.

Simple Example

ExtendedProperties props = new ExtendedProperties();
props.setProperty("test", "\\\\\\\\192.168.1.91\\\\test");
props.getProperty("test"); // => \\192.168.1.91\test

ExtendedProperties props2 = new ExtendedProperties();
props2.combine(props);
props.getProperty("test"); // => \192.168.1.91\test -- Wrong!

16/Mar/08 1:33 AM

6 years, 48 weeks, 1 day ago

18729

No Perforce job exists for this issue.

3

164455

0|i0sidr:

Commons Collections

COLLECTIONS-284

CollectionUtils.removeAll() calls ListUtils.retainAll()

Bug

Closed

Major

Duplicate

Unassigned

Chuck Deal

30/Jan/08 21:01

05/Feb/08 05:47

3.2

0

COLLECTIONS-219

CollectionUtils.removeAll() calls ListUtils.retainAll(). I believe it should actually be

public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.removeAll(collection, remove);
}

05/Feb/08 5:47 AM

12 years, 8 weeks ago

18716

No Perforce job exists for this issue.

0

164445

0|i0sibj:

Commons Collections

COLLECTIONS-353

AbstractLinkedMap firstKey/lastKey JavaDoc reversed

Bug

Closed

Major

Duplicate

Unassigned

Michael Dürig

23/Feb/10 10:15

27/Apr/13 21:26

19/Jun/10 19:28

3.2

4.0

Map

0

COLLECTIONS-262

According to the Javadoc on AbstractLinkedMap#firstKey and AbstractLinkedMap#lastKey the following test shouldn't fail:

LinkedMap map = new LinkedMap();
map.put("one", "one");
map.put("two", "two");
assertEquals("one", map.lastKey());
assertEquals("two", map.firstKey());

19/Jun/10 7:28 PM

9 years, 40 weeks, 3 days ago

18650

No Perforce job exists for this issue.

0

164392

0|i0shzr:

Commons Collections

COLLECTIONS-350

MapUtils.getNumber sends output to System.out

Bug

Closed

Minor

Fixed

Unassigned

Michael Akerman

15/Jan/10 16:35

07/Nov/15 20:59

28/Feb/13 20:07

3.2

3.2.2, 4.0-alpha1, 4.0

0

3600

0%

MapUtils.getNumber calls "logInfo" on a ParseException and it produces output on the System.out, instead of just returning "null" as the documentation states.

Since the expected behavior is to return null, *not* print to System.out. I recommend we remove the call to logInfo and/or remove the System.out.println inside it.

At minimum, if that's not agreed upon, the "side-effect" of writing to System.out should be documented.

I'm happy to offer code for either of these fixes.

0%

3600

15/Jan/10 4:48 PM

10 years, 10 weeks, 4 days ago

18653

No Perforce job exists for this issue.

0

164394

0|i0si07:

Commons Collections

COLLECTIONS-349

The method CollectionUtils.removeAll() call wrongly ListUtils.retainAll()

Bug

Closed

Major

Duplicate

Unassigned

Mathieu

07/Jan/10 10:47

27/Apr/13 21:26

19/Jun/10 19:21

3.2

4.0

Collection

0

COLLECTIONS-219

The method CollectionUtils.removeAll() calls wrongly ListUtils.retainAll() instead of ListUtils.removeAll().

02/Feb/10 12:11 AM

9 years, 40 weeks, 3 days ago

18654

No Perforce job exists for this issue.

0

164395

0|i0si0f:

Commons Collections

COLLECTIONS-266

Issue with MultiKey when serialized/deserialized via RMI

Bug

Closed

Minor

Fixed

Unassigned

Julien Buret

11/Sep/07 21:02

07/Nov/15 20:54

28/Feb/13 19:57

3.2

3.2.2, 4.0-alpha1, 4.0

KeyValue

0

1

COLLECTIONS-576

This is because the hash code of MultiKey is calculated only once.

So if the MultiKey is deserialized in an other jvm, and if one at least of the subkeys defines its hash code with System.identityHashCode() (for example all the enums does), then the hash code of the MultiKey is no longer valid, and you can't retreive the key in your Map.

I fixed it by making the cached hash code field transient, and by recalculating the hash code during deserialization.

12/Sep/07 5:21 PM

11 years, 43 weeks, 4 days ago

18734

No Perforce job exists for this issue.

7

164459

0|i0sien:

Commons Collections

COLLECTIONS-262

probably apidoc error: firstKey() and lastKey() in AbstractLinkedMap

Bug

Closed

Major

Fixed

Unassigned

Lisen Mu

29/Aug/07 04:10

09/Nov/14 14:31

28/Feb/13 19:28

3.2

4.0-alpha1, 4.0

Map

0

1

COLLECTIONS-279, COLLECTIONS-353

In the apidoc or source of org.apache.commons.collections.map.AbstractLinkedMap.firstKey(), it is said that this method "Gets the first key in the map, which is the most recently inserted.", which is exactly the actual behavior of lastKey(), and vice versa.

So I think there is a typo with this class' javadoc.

02/Jan/08 7:23 AM

12 years, 12 weeks, 6 days ago

18738

No Perforce job exists for this issue.

0

164462

0|i0sifb:

Commons Collections

COLLECTIONS-261

Flat3Map.remove() does not return the correct value when size <= 3

Bug

Closed

Major

Fixed

Unassigned

ori

18/Aug/07 14:12

08/Nov/15 21:04

20/Aug/07 14:11

3.2

3.2.2, 4.0

Map

0

Windows XP, SUN JDK 1.5.0_06

final Flat3Map m = new Flat3Map();
m.put( new Integer( 1 ), new Integer( 1 ) );
m.put( new Integer( 0 ), new Integer( 0 ) );
System.out.println( m.remove( new Integer( 1 ) ) );

The above code will print "0" when it should print "1"

20/Aug/07 2:11 PM

12 years, 32 weeks, 1 day ago

18739

No Perforce job exists for this issue.

1

164463

0|i0sifj:

Commons Collections

COLLECTIONS-265

TreeBag allows uncomparable item to be added, breaking toString

Bug

Closed

Minor

Fixed

Unassigned

David Saff

10/Sep/07 19:38

09/Nov/14 14:31

28/Feb/13 20:04

3.2

4.0-alpha1, 4.0

Bag

0

2

The following code throws an exception not when the Object is added, but when toString is called:

TreeBag bag = new TreeBag();
bag.add(new Object());
bag.toString();

Trace:

java.lang.ClassCastException: java.lang.Object
at java.util.TreeMap.compare(TreeMap.java:1093)
at java.util.TreeMap.getEntry(TreeMap.java:347)
at java.util.TreeMap.get(TreeMap.java:265)
at org.apache.commons.collections.bag.AbstractMapBag.getCount(AbstractMapBag.java:116)
at org.apache.commons.collections.bag.AbstractMapBag.toString(AbstractMapBag.java:581)
[...]

In a client program, toString should never throw an exception--it makes debugging much harder, for one thing. I believe that TreeBag should defend against the addition of uncomparable objects, so that toString will never throw an exception.

11/Sep/07 1:35 PM

12 years, 6 days ago

18735

No Perforce job exists for this issue.

2

164460

0|i0siev:

Commons Collections

COLLECTIONS-264

FastTreeMap forgets the comparator

Bug

Closed

Major

Fixed

Unassigned

Thomas Louis

30/Aug/07 16:24

28/Feb/13 19:31

31/Aug/07 09:39

3.2

Map

0

all

In line 359 and 582 of the current 3.2 release you should replace
map = new TreeMap()
with
map = new TreeMap(map.comparator());

Otherwise the underlaying TreeMap looses ist comparator.

31/Aug/07 9:39 AM

12 years, 30 weeks, 4 days ago

18736

No Perforce job exists for this issue.

0

164461

0|i0sif3:

Commons Collections

COLLECTIONS-323

Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap

Bug

Closed

Minor

Fixed

Jochen Wiedmann

Maarten Brak

22/Apr/09 08:43

09/Nov/14 14:31

08/Mar/11 23:39

3.2

4.0-alpha1, 4.0

Map

0

2

86400

0%

Any

The constructor CaseInsensitiveMap(int initialCapacity) throws an IllegalArgumentException if "the initial capacity is less than one". This is inconsistent with the standard Java HashMap constructor HashMap(int initialCapacity), which throws an if IllegalArgumentException if "the initial capacity is negative".

Thus:
new HashMap(0) ==> no exception
new CaseInsensitiveMap(0) ==> IllegalArgumentException.

This inconsistency is confusing.

Actions:
- Change Javadoc (this shouldn't be a problem in practice since surely there is no code around depending on the fact that the constructor throws an IllegalArgumentException :-))
- Change code.

0%

86400

20/May/09 4:32 AM

7 years, 34 weeks, 5 days ago

18678

No Perforce job exists for this issue.

1

164415

0|i0si4v:

Commons Collections

COLLECTIONS-307

SetUniqueList.subList().contains() method checks against full parent list, not sublist range

Bug

Closed

Minor

Fixed

Unassigned

Christian Semrau

12/Nov/08 16:59

08/Nov/15 21:12

28/Feb/13 20:03

3.2

3.2.2, 4.0-alpha1, 4.0

List

0

The view returned by the subList() method of a SetUniqueList checks contains() against the set of the original list.

As shown by the following test snippet.

List list = new ArrayList();
List uniqueList = SetUniqueList.decorate(list);
uniqueList.add("Hello");
uniqueList.add("World");
List subList = list.subList(0, 0);
List subUniqueList = uniqueList.subList(0, 0);
assertFalse(subList.contains("World")); // passes
assertFalse(subUniqueList.contains("World")); // fails

29/Dec/08 5:10 AM

11 years, 12 weeks, 1 day ago

18694

No Perforce job exists for this issue.

1

164427

0|i0si7j:

Commons Collections

COLLECTIONS-256

ListUtils.transformedList(list, transformer) doesn't transform

Bug

Closed

Major

Duplicate

Unassigned

Kurtis Williams

08/Jun/07 22:43

09/Nov/14 14:31

27/Apr/13 21:42

3.2

4.0-alpha1, 4.0

List

0

COLLECTIONS-288

Java 1.5

The static method ListUtils.transformedList(List list, Transformer trans) does not apply the transformer before returning the list. I've traced into the code and it falls all the way through to the TransformedCollection constructor which has documentation that states that items existing in the list are NOT transformed. This yields bizarre unexpected behavior for this method.

Conversely, the ListUtils.predicatedList(List list, Predicate pred) DOES apply the predicate. These methods are very similar but behave inconsistently.

If the transformer is not applied to the list, the method's usefulness is somewhat limited and causes the user to create an extra unwanted list in some circumstances:

// To transform an existing list
List myList = ... some list to be transformed ...
List transformed = ListUtils.transformedList(new ArrayList(), myTransformer);
transformed.addAll(myList);

I would expect a much shorter implementation such as:

List transformed = ListUtils.transformedList(myList, myTransformer)

15/Aug/07 5:22 AM

12 years, 29 weeks, 6 days ago

18744

No Perforce job exists for this issue.

1

164467

0|i0sigf:

Commons Collections

COLLECTIONS-257

CollectionUtils.removeAll() calls ListUtils.retainAll()

Bug

Closed

Major

Duplicate

Unassigned

Sami Kallio

25/Jun/07 10:53

27/Apr/13 21:26

26/Jun/07 15:40

3.2

4.0

Collection

0

/**
* Returns a collection containing all the elements in <code>collection</code>
* that are also in <code>retain</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>c.retainAll(retain);</code>.
*
* @param collection the collection whose contents are the target of the #retailAll operation
* @param retain the collection containing the elements to be retained in the returned collection
* @return a <code>Collection</code> containing all the elements of <code>collection</code>
* that occur at least once in <code>retain</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection retainAll(Collection collection, Collection retain) {
return ListUtils.retainAll(collection, retain);
}

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}

I guess the later method shoud be:
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.removeAll(collection, remove);
}

26/Jun/07 3:40 PM

12 years, 40 weeks ago

18743

No Perforce job exists for this issue.

0

164466

0|i0sig7:

Commons Collections

COLLECTIONS-315

CollectionUtils.removeAll calls the wrong ListUtils method

Bug

Closed

Major

Duplicate

Unassigned

Christopher

03/Feb/09 19:30

01/May/12 12:03

03/Feb/09 20:40

3.2

Core

0

COLLECTIONS-219

Using version 3.2.1 as downloaded from maven's public repository.

CollectionUtils.removeAll should call ListUtils.removeAll instead of ListUtils.retainAll.

Currently
{{public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}}}

Suggested
{{public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.*removeAll*(collection, remove);
}}}

01/May/12 12:03 PM

7 years, 47 weeks ago

18686

No Perforce job exists for this issue.

0

164422

0|i0si6f:

Commons Collections

COLLECTIONS-236

CollectionUtils.filter filters the inverse of what it is documented to filter

Bug

Closed

Major

Invalid

Unassigned

Lee Wexler

21/Nov/06 14:12

22/Nov/06 16:26

3.2

Collection

0

1

The documentation states that when the predicate returns *false* the item will be removed.
The implementation removes those items that return true.

22/Nov/06 4:26 PM

13 years, 18 weeks, 6 days ago

18763

No Perforce job exists for this issue.

0

164482

0|i0sijr:

Commons Collections

COLLECTIONS-246

LoopingListIterator behaves unexpected on next and previous mixed

Bug

Closed

Blocker

Invalid

Unassigned

Frank Hefter

20/Mar/07 09:07

28/Feb/13 19:52

26/Apr/08 15:17

3.2

Iterator

0

2

COLLECTIONS-239

JDK 1.4.2_12
Common Collections 3.2

Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of "cursor" var seems to be wrong implemented ) to cause this problem. If so maybe we have to implement it in a different way.

Testcase (it runs without hassle but the comments show whats wrong):
-------------------------------------------
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;

public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add("0"); al.add("1"); al.add("2");
LoopingListIterator it = new LoopingListIterator(al);
assertEquals("0", it.next()); // This is OK
// here I am on "0"
assertEquals("0", it.previous()); // Wrong ! This should be 2!
// here I am on "0" too! This is wrong.
assertEquals("2", it.previous());
assertEquals("1", it.previous());
assertEquals("0", it.previous());
assertEquals("2", it.previous());
// here I am on "2"
assertEquals("2", it.next()); // Wrong ! This should be 0!
// here I am on "2" too! This is wrong.
assertEquals("0", it.next());
assertEquals("1", it.next());
// here I am on "1"
assertEquals("1", it.previous()); // Wrong ! This should be 0!
}
}
-------------------------------------------

Thanks for your help.

20/Mar/07 11:12 PM

11 years, 48 weeks, 3 days ago

18753

No Perforce job exists for this issue.

3

164475

0|i0sii7:

Commons Collections

COLLECTIONS-249

SetUniqueList.addAll(int index, Collection coll) adds to end of list instead of at specified index

Bug

Closed

Minor

Fixed

Unassigned

Joe Kelly

20/Apr/07 19:10

07/Nov/15 20:26

28/Feb/13 20:05

3.2

3.2.2, 4.0-alpha1, 4.0

List

0

1

When you call SetUniqueList.addAll(int index, Collection coll), it incorrectly adds the new elements to the end of the list instead of at the specified index.

21/Apr/07 1:45 PM

12 years, 10 weeks, 2 days ago

18750

No Perforce job exists for this issue.

2

164473

0|i0sihr:

Commons Collections

COLLECTIONS-240

MultiValueMap should implement Serializable

Bug

Closed

Blocker

Fixed

Unassigned

Wouter de Vaal

20/Jan/07 14:09

09/Nov/14 14:31

28/Feb/13 20:04

3.2

4.0-alpha1, 4.0

Map

11

6

COCOON-2146, COCOON-2151

Collection classes should be serializable as they are frequently used in model classes which need to be serializable, for example in a HttpSession object within a servlet container cluster.

03/May/07 7:38 PM

11 years, 44 weeks, 4 days ago

18759

No Perforce job exists for this issue.

1

163862

0|i0seq7:

Commons Collections

COLLECTIONS-239

In LinkIterator hasPrevious() is not working properly for the first entry

Bug

Closed

Major

Won't Fix

Unassigned

Michael Pavlov

17/Jan/07 09:26

27/Apr/13 21:25

26/Mar/08 05:36

3.2

Iterator

0

1

COLLECTIONS-246

Windows XP, jdk-1.5.0_02

In hasPrevious() method of LinkIterator 'next' field is used, that is not correct - method returns 'true' for the first entry. 'last' field should be used insted.

29/Jan/07 11:18 PM

7 years, 34 weeks, 5 days ago

18760

No Perforce job exists for this issue.

1

164480

0|i0sijb:

Commons Collections

COLLECTIONS-237

MultiValueMap: behavior of entrySet().iterator() is not the expected one

Bug

Closed

Major

Fixed

Unassigned

Nils Kaiser

12/Dec/06 18:09

09/Nov/14 14:31

27/Apr/13 11:09

3.2

4.0-alpha1, 4.0

Map

1

0

The entrySet() method of the MultiValueMap delegates the entrySet() call to the decorated map, which is HashMap by default. The default hashmap iterator is used, which causes the iterator to return one Map.Entry for every key. The value returned for the key is an ArrayList, and not the value of the entry which was put into the map.

The expected behavior would be the iterator to return the whole set of entries in the map, which requires iteration over the different array lists contained in the decorated map.

12/Dec/06 9:57 PM

6 years, 47 weeks, 3 days ago

18762

No Perforce job exists for this issue.

0

90387

0|i0ftk7:

Commons Collections

COLLECTIONS-228

MultiValueMap put and putAll do not return the correct values

Bug

Closed

Minor

Fixed

Stephen Colebourne

28/Oct/06 12:14

07/Nov/15 20:47

28/Feb/13 20:25

3.2

3.2.2, 4.0-alpha1, 4.0

Map

0

MultiValueMap put and putAll do not return the correct values.

putAll(Object, Collection) should return true if the map is changed. But if the key is new then this behaviour fails.

put(Object, Object) should return the added value if the map is changed. But if the key is new then this behaviour fails.

This was hidden because the test case referred to MultiHashMap and not MultValueMap.

13 years, 22 weeks, 3 days ago

18771

No Perforce job exists for this issue.

0

164490

0|i0silj:

Commons Collections

COLLECTIONS-221

CompositeCollection, CompositeMap, CompositeSet should implement Serializable

Bug

Closed

Minor

Fixed

Unassigned

Pal Denes

12/Aug/06 17:10

09/Nov/14 14:31

28/Feb/13 20:08

3.2

4.0-alpha1, 4.0

Collection, Map, Set

1

These classes should implement Serializable as usually all generial collection classes do. (At least I cannot think of a reason why they shouldn't and currently their usage is quite limited, like in RMI or http-sessions.)

03/May/07 7:39 PM

11 years, 46 weeks ago

18778

No Perforce job exists for this issue.

1

164494

0|i0simf:

Commons Collections

COLLECTIONS-222

CollectionUtils removeAll is actually retainAll

Bug

Closed

Major

Duplicate

Unassigned

Tim Lenz

18/Aug/06 17:43

18/Aug/06 19:01

3.2

Collection

0

COLLECTIONS-219

The removeAll(Collection collection, Collection remove) method calls ListUtils.retainAll(collection, remove)
instead of ListUtils.removeAll(Collection collection, Collection remove)

Should be an easy fix

18/Aug/06 6:08 PM

13 years, 32 weeks, 4 days ago

18777

No Perforce job exists for this issue.

0

164493

0|i0sim7:

Commons Collections

COLLECTIONS-219

The CollectionUtils.removeAll method calls the ListUtils.retainAll method instead of the ListUtils.removeAll method.

Bug

Closed

Major

Fixed

Stephen Colebourne

Tom Leccese

02/Aug/06 17:37

07/Nov/15 19:51

28/Feb/13 20:25

3.2

3.2.2, 4.0-alpha1, 4.0

Core

0

4

COLLECTIONS-487, COLLECTIONS-357, COLLECTIONS-437, COLLECTIONS-222, COLLECTIONS-284, COLLECTIONS-315, COLLECTIONS-349, COLLECTIONS-435

The CollectionUtils.removeAll method calls the ListUtils.retainAll method instead of the ListUtils.removeAll method.

02/Aug/06 8:23 PM

4 years, 19 weeks, 3 days ago

18780

No Perforce job exists for this issue.

0

115442

0|i0k3uv:

Commons Collections

COLLECTIONS-217

Flat3Map.Entry.setValue() overwrites other Entry values

Bug

Closed

Critical

Fixed

Stephen Colebourne

Matt Bishop

18/Jul/06 17:42

08/Nov/15 20:21

18/Jul/06 22:02

3.2

3.2.2, 4.0

Map

1

0

JDK 1.4, WinXP

Flat3Map's Entry objects will overwrite other Entry's values if Entry.setValue() is called on one. It should only overwrite the Entry at hand.

I've looked at the source, and the case statement incorrectly falls through, rather than returning like it should:

Flat3Map.java, lines 646-660:

public Object setValue(Object value) {
if (canRemove == false) {
throw new IllegalStateException(AbstractHashedMap.SETVALUE_INVALID);
}
Object old = getValue();
switch (nextIndex) {
case 3:
parent.value3 = value;
case 2:
parent.value2 = value;
case 1:
parent.value1 = value;
}
return old;
}

With this code, if I set the value of the third item in the EntrySet, then all three values are set to the new value.

18/Jul/06 8:20 PM

13 years, 37 weeks ago

18782

No Perforce job exists for this issue.

0

164497

0|i0sin3:

Commons Collections

COLLECTIONS-220

Serialization/Deserialization doesn't work well with empty buffers.

Bug

Closed

Minor

Fixed

Unassigned

Jose Luis Huertas

07/Aug/06 13:53

27/Nov/15 21:11

28/Feb/13 20:08

3.2

Buffer

1

COLLECTIONS-432

When I serialize the queue to disk an it has elements, all works ok, but when I serialize an empty queue I have some problems when I create a new object using the serialized file.

When I deserialize the queue it has a 'buffer' with size 1 (with null content), 'tail' and 'head' fields are 0 (they are declared transient). So, when I try to add a new object to the queue, the sentence:

Object[] tmp = new Object[((buffer.length - 1) * 2) + 1];

Is executed in the add() method to increase the buffer length, but the buffer remains with the same size! (buffer.length = 1 --> (1 - 1) * 2 + 1 = 1). So, the object is added and when the tail is going to be incremented, it is reset to 0!!

private int increment(int index) {
index++;
if (index >= buffer.length) {
index = 0;
}
return index;
}

So it is impossible to add new elements after an empty queue has been serialized / deserialized.

I attach a simple TestCase where this is proved. The example works when you use XMLEncoder to serialize the buffer but doesn't work if you use ObjectOutputStream or XStream.

29/Dec/06 12:27 AM

6 years, 48 weeks, 1 day ago

18779

No Perforce job exists for this issue.

3

164495

0|i0simn:

Commons Collections

COLLECTIONS-214

ExtendedProperties - field include should be non-static and private

Bug

Closed

Major

Fixed

Stephen Colebourne

Sebb

18/Jun/06 18:54

27/Apr/13 21:32

18/Jul/06 22:44

3.2

0

COLLECTIONS-351

The field "include" in ExtendedProperties is currently static and protected, yet has instance get/set accessors.

Given that there are accessors, it seems unnecessary for the field to be protected - it could be private.

The field should also surely be non-static - or the accessors should be made static, if the field really is supposed to be shared among instances.

18/Jul/06 10:44 PM

6 years, 47 weeks, 3 days ago

18785

No Perforce job exists for this issue.

0

164500

0|i0sinr:

Commons Collections

COLLECTIONS-87

[collections] Implement a TimeoutBuffer class

Bug

Closed

Major

Won't Fix

Unassigned

James Carman

12/Nov/05 05:35

15/Mar/08 21:36

3.2

0

Operating System: other
Platform: Other

Please implement a TimeoutBuffer wrapper class which blocks on read()/get()
operations until a timeout expires.

14 years, 18 weeks, 6 days ago

18911

No Perforce job exists for this issue.

0

37472

164621

0|i0sjen:

Commons Collections

COLLECTIONS-17

[collections] Enhance BlockingBuffer to allow for a timeout value

Bug

Closed

Major

Fixed

Unassigned

James Carman

23/Nov/05 22:00

15/Mar/08 21:35

3.2

0

Operating System: other
Platform: Other

BlockingBuffer currently waits forever. Add the capability to specify a timeout
value to BlockingBuffer.

14 years, 18 weeks, 6 days ago

18981

No Perforce job exists for this issue.

0

37607

164691

0|i0sju7:

Commons Collections

COLLECTIONS-29

[collections] "Upload to m2 repo @ibiblio.org"

Bug

Closed

Major

Invalid

Unassigned

David J. M. Karlsen

15/May/06 21:27

18/Jul/06 22:04

3.2

0

1

Operating System: other
Platform: Other

Could somebody upload collections 3.2 to www.ibiblio.org/maven2 repo?

18/May/06 6:52 AM

13 years, 37 weeks ago

18969

No Perforce job exists for this issue.

0

39584

164679

0|i0sjrj:

Commons Collections

COLLECTIONS-116

[collections] Getting rid of some javadoc warn messages (3.2-dev)

Bug

Closed

Minor

Fixed

Unassigned

Olaf Krische

04/Oct/04 06:07

15/Mar/08 21:36

3.2

0

Operating System: other
Platform: Other

Salut.

Just called javadoc to create the java documentation and wondered about
some warnings, though everything seemed to be at the right place:

Tag @link: can't find removeLRU(LinkEntry) in
org.apache.commons.collections.map.LRUMap
Tag @link: can't find moveToMRU(LinkEntry) in
org.apache.commons.collections.map.LRUMap

"LinkEntry" is a static class in AbstractLinkedMap, LRUMap derives from
AbstractLinkedMap. Why javadoc does not know about "LinkEntry" then, while
java itself does?

The solution comes from the javadoc-API:

"Nested classes must be specified as outer.inner, not simply inner, for all forms."

(http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javadoc.html#@see)

That is the reason, why javadoc spews warnings, when {@link
#removeLRU(LinkEntry)} is used.

The correct code will look like this then:

{@link #removeLRU(AbstractLinkedMap.LinkEntry)}

Actually i have found this only in collections.map.LRUMap, its really a minor
thing. But even Eclipse gave me the "wrong" code...

Thanks for the collections, we use them intensily here :-)

Ciao.

17/Oct/04 4:43 AM

15 years, 13 weeks ago

18882

No Perforce job exists for this issue.

9

31519

164592

0|i0sj87:

Commons Collections

COLLECTIONS-52

[collections] Method that add a Object to a Collection if it was not null

Bug

Closed

Major

Fixed

Unassigned

Rafael U. C. Afonso

10/Jul/04 08:52

15/Mar/08 21:35

3.2

0

Operating System: other
Platform: Other

It would be a new static method to CollectionUtils class. It would retur
boolean because add() method from Collection returns a boolean. It would had
only a line:

public static boolean addNotNull(Collection c, Object o) {
return (o != null)? c.add(o): false;
}

Of course if c was null, it will throw a NullPointerException.
Aparently it is possible use a PredicatedCollection with NotNullPredicate. But
it will trhow a IllegalArgumentException if o was null. It is not interesting.

18/Jul/04 4:41 AM

15 years, 37 weeks, 2 days ago

18946

No Perforce job exists for this issue.

0

30020

164656

0|i0sjmf:

Commons Collections

COLLECTIONS-379

Bugs In Javadoc Comment in the CollectionUtils class

Bug

Closed

Major

Fixed

Unassigned

SHIN HWEI TAN

22/Sep/11 02:45

18/Mar/20 02:41

09/Nov/14 14:31

26/Jul/12 21:19

3.2

4.0-alpha1, 4.0

Collection

0

2

1200

0%

System independent

I came across the following bugs in the Javadoc comments in the method below in the CollectionUtils class:

1.
{quote}
/**
* Selects all elements from input collection which match the given predicate
* and adds them to outputCollection.
* 
* If the input collection or predicate is null, there is no change to the
* output collection.
*
* @param inputCollection the collection to get the input from, may be null
* @param predicate the predicate to use, may be null
* @*param outputCollection the collection to output into, may not be null*
*/
public static void select(Collection inputCollection, Predicate predicate, Collection outputCollection) {
{quote}
_This method will execute normally when calling select((Collection)null, (Predicate)null, (Collection)null) but the comment clearly states that outputCollection may not be null_

2.
{quote}
/**
* Selects all elements from inputCollection which don't match the given predicate
* and adds them to outputCollection.
* 
* If the input predicate is <code>null</code>, no elements are added to <code>outputCollection</code>.
*
* @param inputCollection the collection to get the input from, may be null
* @param predicate the predicate to use, may be null
* @*param outputCollection the collection to output into, may not be null*
*/
public static void selectRejected(Collection inputCollection, Predicate predicate, Collection outputCollection) {
{quote}
_This method will execute normally when calling selectRejected((Collection)null, (Predicate)null, (Collection)null) but the comment also clearly states that outputCollection may not be null_

3.
{quote}
/**
* Transforms all elements from the inputIterator with the given transformer
* and adds them to the outputCollection.
* 
* If the input iterator or transformer is null, there is no change to the
* output collection.
*
* @param inputIterator the iterator to get the input from, may be null
* @param transformer the transformer to use, may be null
* @*param outputCollection the collection to output into, may not be null*
* @return the outputCollection with the transformed input added
* @*throws NullPointerException if the output collection is null*
*/
public static Collection collect(Iterator inputIterator, final Transformer transformer, final Collection outputCollection) {
{quote}
_This method will execute normally when calling collect((Iterator)null, (Transformer)null, (Collection)null) but the comment clearly states that NullPointerException will be thrown when the outputCollection is null_

4.
{quote}
/**
* Transforms all elements from inputCollection with the given transformer
* and adds them to the outputCollection.
* 
* If the input collection or transformer is null, there is no change to the
* output collection.
*
* @param inputCollection the collection to get the input from, may be null
* @param transformer the transformer to use, may be null
* @*param outputCollection the collection to output into, may not be null*
* @return the outputCollection with the transformed input added
* @*throws NullPointerException if the output collection is null*
*/
public static Collection collect(Collection inputCollection, final Transformer transformer, final Collection outputCollection) {
{quote}
_This method will execute normally when calling collect((Collection)null, (Transformer)null, (Collection)null) but the comment clearly states that NullPointerException will be thrown when the outputCollection is null_

The bugs in the Javadoc comments above could be confusing to the users of the Common Collection library and they could be fixed easily by the developers..

There are a few ways to fix the:
1. Throwing the NullPointerException explicitly when the outputCollection is null.
2. Changing the Javadoc comments to include the case where all of the parameters are null.

0%

1200

test

26/Jul/12 9:19 PM

7 years, 34 weeks, 5 days ago

3625

No Perforce job exists for this issue.

0

164375

0|i0shvz:

Commons Collections

COLLECTIONS-652

An obvious bug in CollectionUtils

Bug

Closed

Minor

Fixed

Unassigned

samray leung

12/Jul/17 08:49

02/Aug/17 16:50

3.2.1

3.2.2

Collection

0

1

600

0%

windows 7, jdk8. This bug is so obvious so I think it is nothing to do with environment

In CollectionUtils.java:
Line number: 1121

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
The method should call ListUtils.removeAll(Collection collection, Collection remove) instead of calling ListUtils.retailAll(collection,remove)

0%

600

easyfix

02/Aug/17 4:50 PM

2 years, 32 weeks, 6 days ago

9223372036854775807

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/

No Perforce job exists for this issue.

0

9223372036854775807

Patch, Important

0|i3hf0f:

Commons Collections

COLLECTIONS-538

ExtendedProperties causes AccessControlException when framework is called from a script

Bug

Closed

Major

Fixed

Unassigned

Trejkaz

03/Dec/14 23:58

27/Nov/15 21:11

08/Nov/15 15:08

3.2.1

3.2.2

Collection

0

1

Java security manager enabled

We're using Velocity 1.7, which depends upon Commons Collections 3.x series' ExtendedProperties class.

ExtendedProperties has these constructors where it looks up the file separator using the least convenient means possible:

{code}
public ExtendedProperties() {
this.fileSeparator = System.getProperty("file.separator");
// ...
}
{code}

For us, this is all being called from untrusted code, so this fails with AccessControlException.

I think that instead of using the system property here, it is customary to use the File.separator constant.

If you absolutely _must_ use System.getProperty() to fetch this value, it should at least be done from a doPrivileged() block.

Also I had a quick check of Commons Collections 4 to see if this issue had been fixed, but couldn't immediately see what happened to this class. If it did turn out to have been fixed in v4, maybe Velocity could be encouraged to update to v4, but I haven't seen any updates from them in 4 years, so it's probably not a good sign.

04/Dec/14 9:33 AM

4 years, 19 weeks, 2 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i231d3:

Commons Collections

COLLECTIONS-444

SetUniqueList may become inconsistent

Bug

Closed

Major

Fixed

Unassigned

Thomas Vahrst

25/Feb/13 16:08

08/Nov/15 21:36

17/Apr/13 18:13

3.2.1

3.2.2, 4.0-alpha1, 4.0

List

0

2

COLLECTIONS-310

I found this bug during my work on issue COLLECTIONS-310 :

When you 'set' an element to a position that contains this element, it is removed from the internal set. This leads to the situation that
- invocing get() returns the element
- invocing contains() returns false.

Extending the existing test method for set:
{code}
public void testSet() {
final SetUniqueList<E> lset = new SetUniqueList<E>(new ArrayList<E>(), new HashSet<E>());

// Duplicate element
final E obj1 = (E) new Integer(1);
final E obj2 = (E) new Integer(2);
final E obj3 = (E) new Integer(3);

lset.add(obj1);
lset.add(obj2);
lset.set(0, obj1);
assertEquals(2, lset.size());
assertSame(obj1, lset.get(0));
assertSame(obj2, lset.get(1));

assertTrue(lset.contains(obj1)); // fails !
assertTrue(lset.contains(obj2));

{code}

25/Feb/13 9:48 PM

6 years, 48 weeks, 6 days ago

314421

No Perforce job exists for this issue.

0

314766

0|i1i9av:

Commons Collections

COLLECTIONS-407

ListOrderedSet.removeAll() is slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

01/Jun/12 17:55

09/Nov/14 14:31

19/Jun/12 19:00

3.2.1

4.0-alpha1, 4.0

0

2

COLLECTIONS-408, COLLECTIONS-409

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in ListOrderedSet.removeAll().
It appears in version 3.2.1 and also in revision 1344775 (31 May
2012). I have attached a test that exposes this problem and a
one-line patch that fixes it. On my machine, for this test, the patch
provides a 317X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 3812

The output for the patched version is:
Time is 12

As the patch shows, the problem is in
ListOrderedSet.remove(Object object). The code for this method is:

boolean result = collection.remove(object);
setOrder.remove(object);
return result;

The patch changes it to :

boolean result = collection.remove(object);
if (result) setOrder.remove(object);
return result;

The "setOrder.remove(object)" is not necessary if
"collection.remove(object)" did not find the object.

This small change speeds up
ListOrderedSet.ListOrderedSet.removeAll(Collection<?> coll) because
ListOrderedSet.ListOrderedSet.removeAll(Collection<?> coll) iterates
over all the elements in "coll" and calls
ListOrderedSet.remove(Object object). So the un-patched code has
quadratic complexity, while the patched code has linear complexity.

Is this truly a bug, or am I missing something here? If so, can you
please confirm if the patch is correct?

Thanks,

Adrian

19/Jun/12 7:16 AM

7 years, 40 weeks ago

292951

No Perforce job exists for this issue.

2

164353

0|i0shr3:

Commons Collections

COLLECTIONS-406

ListUtils.subtract is very slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

27/May/12 19:52

09/Nov/14 14:31

03/Jun/12 10:25

3.2.1

4.0-alpha1, 4.0

0

3

java 1.6.0_24
Ubuntu 11.10

Hi,

ListUtils.subtract is very slow when subtracting two large lists. The
root cause of this problem is similar to the root cause of the
previously fixed COLLECTIONS-328 in ListUtils, i.e., quadratic
complexity instead of linear complexity.

I am encountering this problem in version 3.2.1 and also in revision
1342815 (May 25th 2012). I have attached a test that exposes this
problem and a simple patch. On my machine, for the attached test,
this patch provides a 95X speedup.

To run the test, just do:

$ java Test

Currently, the code for ListUtils.subtract is:

final ArrayList<E> result = new ArrayList<E>(list1);
for (E e : list2) {
result.remove(e);
}
return result;

which is quadratic, because result.remove(e) has linear complexity.

The attached patch makes the remove() be constant complexity by
removing from an org.apache.commons.collections.bag.HashBag. I use
HashBag and not HashSet because ListUtils.subtract needs to respect
the cardinality when there are repeated objects in the list.

As mentioned in COLLECTIONS-328 discussion, for small lists, there is
some overhead for creating the HashBag. This can be fixed with a
threshold, but I did not implement it in my patch because the
COLLECTIONS-328 patch does not implement it.

Unlike the patch for COLLECTIONS-328, my patch does not choose the
list to iterate over based on size, because of the cardinality
requirement in subtract. This means the code could be made even
faster if we could use something like a LinkedHashBag but neither
Apache Collections nor standard Java libraries have such a class.
Even so, this patch is still a lot faster than the original version.

Is this truly a bug, or am I missing something here? If so, can you
please confirm if the patch is correct?

Thanks,

Adrian

03/Jun/12 10:25 AM

7 years, 42 weeks, 2 days ago

292952

No Perforce job exists for this issue.

2

164354

0|i0shrb:

Commons Collections

COLLECTIONS-401

Inconsistent Javadoc comment and code in removeAll(Collection<E>, Collection<?>) in org.apache.commons.collections.ListUtils

Bug

Closed

Major

Not A Problem

Unassigned

SHIN HWEI TAN

30/Mar/12 03:02

27/Nov/15 21:47

26/Jul/12 21:02

3.2.1

Collection

0

1

180

0%

The Javadoc comment below states that the method "throws NullPointerException if either parameter is null".
/*......
*
* @throws NullPointerException if either parameter is null
*/
public static <E> List<E> removeAll(Collection<E> collection, Collection<?> remove) {
..
}
However, when called with two null collections (i.e., "removeAll((Collection)null, (Collection)null)"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if either parameter is null" from the Javadoc.
or
3. Change "@throws NullPointerException if either parameter is null" to "@throws NullPointerException if the first collection is null or (the first collection is non-empty and the second collection is null)".

0%

180

javadoc

09/Apr/12 5:54 PM

7 years, 39 weeks, 6 days ago

233875

No Perforce job exists for this issue.

0

164358

0|i0shs7:

Commons Collections

COLLECTIONS-400

Inconsistent Javadoc comment and code in addIgnoreNull(Collection<T>, T) in org.apache.commons.collections.CollectionUtils

Bug

Closed

Major

Fixed

Unassigned

SHIN HWEI TAN

30/Mar/12 02:59

09/Nov/14 14:31

09/Apr/12 17:27

3.2.1

4.0-alpha1, 4.0

Collection

0

180

0%

Platform independent

The Javadoc comment below states that the method "throws NullPointerException if the collection is null".
/**
.....
* @param collection the collection to add to, must not be null
* @param object the object to add, if null it will not be added
* @return true if the collection changed
* @throws NullPointerException if the collection is null
*/
public static <T> boolean addIgnoreNull(Collection<T> collection, T object) {
return (object != null && collection.add(object));
}
However, when called with an null collection and a null object (i.e., "addIgnoreNull((Collection)null, null)"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (collection == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if the collection is null" from the Javadoc.
or
3. Change "@throws NullPointerException if the collection is null" to "@throws NullPointerException if the collection is null and the object is non-null)".

0%

180

javadoc

09/Apr/12 5:27 PM

7 years, 50 weeks, 1 day ago

233874

No Perforce job exists for this issue.

0

164359

0|i0shsf:

Commons Collections

COLLECTIONS-402

Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils

Bug

Closed

Major

Invalid

Unassigned

SHIN HWEI TAN

30/Mar/12 03:42

27/Nov/15 21:47

26/Jul/12 20:59

3.2.1

Collection

0

180

0%

Platform Independent

The Javadoc comment below states that the method "throws NullPointerException if either list is null".
/*......
*
* @throws NullPointerException if either list is null
*/
public static List intersection(final List list1, final List list2)
..
}
However, when called with a null list1 and an empty list2(i.e., "intersection((List)null, new ArrayList())"), the method executes normally without throwing any exception.

Suggested Fixes:
1. Add code "if (list1 == null) throw NullPointerException();" at the beginning of the method body.
or
2. Remove "@throws NullPointerException if either list is null" from the Javadoc.
or
3. Change "@throws NullPointerException if either list is null" to "@throws NullPointerException if list2 is null or (the list2 is non-empty and the list1 is null)".

0%

180

09/Apr/12 5:56 PM

7 years, 50 weeks, 1 day ago

233877

No Perforce job exists for this issue.

0

164357

0|i0shrz:

Commons Collections

COLLECTIONS-472

wasted work in AbstractMapBag.containsAll()

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

03/Jun/13 22:59

09/Nov/14 14:31

09/Jun/13 18:35

3.2.1

4.0-alpha1, 4.0

Bag

0

1

any

The problem appears in version 3.2.1 and in revision 1489197. I
attached a one-line patch that fixes it.

In method "AbstractMapBag.containsAll", the loop over
"other.uniqueSet()" should return immediately after "result" becomes
"false", because "result = result && contains;" can never become
"true" again. All the iterations after "result" becomes "false" do
not perform any useful work, at best they just set "result" again to
"false".

patch,, performance

09/Jun/13 6:35 PM

6 years, 41 weeks, 2 days ago

331088

No Perforce job exists for this issue.

1

331421

0|i1l4an:

Commons Collections

COLLECTIONS-453

findBugs Warnings: several classes in package functors may expose their internal representation

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

27/Apr/13 12:23

09/Nov/14 14:31

05/May/13 16:16

3.2.1

4.0-alpha1, 4.0

0

Several classes (e.g. SwitchTransformer) take in their constructor an array as input which is not copied/cloned.
Thus its internal representation may be changed externally.

The corresponding factory methods *do* copy the input arguments thus we have two choices:

* move the copy from the factory methods to the ctors
* make the ctors private to prevent their use

6 years, 46 weeks, 2 days ago

325382

No Perforce job exists for this issue.

0

325727

0|i1k4wv:

Commons Collections

COLLECTIONS-454

findBugs Warning: Flat3Map - 3 iterators which are "both an Iterator and a Map.Entry"

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

27/Apr/13 12:26

09/Nov/14 14:31

28/Apr/13 18:53

3.2.1

4.0-alpha1, 4.0

0

The iterators should be rewritten as suggested by findbugs.

28/Apr/13 2:54 PM

6 years, 47 weeks, 2 days ago

325383

No Perforce job exists for this issue.

1

325728

0|i1k4x3:

Commons Collections

COLLECTIONS-435

CollectionUtils.removeAll() calls ListUtils.retainAll()

Bug

Closed

Major

Duplicate

Unassigned

Mikolaj Rydzewski

14/Nov/12 10:13

14/Nov/12 10:26

3.2.1

Collection

0

1

COLLECTIONS-219

A snippet from CollectionUtils.java:

{code:title=CollectionUtils.java}
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}
{code}
It should call ListUtils.removeAll() instead.

7 years, 18 weeks, 6 days ago

257655

No Perforce job exists for this issue.

0

115439

0|i0k3u7:

Commons Collections

COLLECTIONS-425

performance problem in ListOrderedMap.remove()

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

24/Jul/12 18:15

09/Nov/14 14:31

25/Jul/12 21:15

3.2.1

4.0-alpha1, 4.0

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in ListOrderedMap.remove().
It appears in version 3.2.1 and also in revision 1365132. I attached
a test that exposes this problem and a simple patch that fixes it. On
my machine, for this test, the patch provides a 213X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 1497

The output for the patched version is:
Time is 7

The patch changes the "ListOrderedMap.remove(Object key)" code from:

{code:java|borderStyle=solid}
Object result = getMap().remove(key);
insertOrder.remove(key);
{code}

to:

{code:java|borderStyle=solid}
if (decorated().containsKey(key)) {
result = decorated().remove(key);
insertOrder.remove(key);
}
{code}

If "decorated()" does not contain the key, there is no need to remove
it. This change significantly speeds up the code by avoiding the call
to "insertOrder.remove(key)", which is very expensive because
"insertOrder" is an ArrayList, and removing from an ArrayList is a
linear time operation.

It may appear that the check "if (decorated().containsKey(key))" may
slow down the code when "decorated()" contains the key, because it
adds a new operation "decorated().containsKey(key)", without avoiding
the calls to "getMap().remove(key)" and "insertOrder.remove(key)".

I attached a test, TestWorstCase.java, that show that, even when
removing only existing keys (i.e., "decorated().containsKey(key)"
always returns "true"), the patched version takes almost the same time
as the un-patched version.

To run TestWorstCase, just do:

$ java TestWorstCase

The output for the un-patched version for TestWorstCase is:
Time is 96

The output for the patched version for TestWorstCase is:
Time is 97

The reason why the patch does not slow down the code, even for this
worst case, is because "decorated().containsKey(key)" is a
"containsKey()" on a HashMap (very fast, constant time operation),
whereas "insertOrder.remove(key);" is a "remove()" on an ArrayList
(very slow, linear time operation). So the time taken by
"decorated().containsKey(key)" is negligible compared to the time
taken by "insertOrder.remove(key);". In other words, most of the time
is spent inside "insertOrder.remove(key)", and performing one
additional fast operation cannot be noticed.

Is this truly a bug? If so, can you please confirm if the patch is
correct?

Thanks,

Adrian

25/Jul/12 9:15 PM

7 years, 34 weeks, 6 days ago

292941

No Perforce job exists for this issue.

3

164343

0|i0shov:

Commons Collections

COLLECTIONS-426

performance problem in ListOrderedSet.retainAll()

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

24/Jul/12 22:04

27/Nov/15 21:11

27/Jan/15 15:06

3.2.1

4.0-alpha1, 4.0, 4.1

0

1

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in ListOrderedSet.retainAll().
It appears in version 3.2.1 and also in revision 1365132. I attached
a test that exposes this problem and a patch that fixes it. On my
machine, for this test, the patch provides a 263X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 3682

The output for the patched version is:
Time is 14

The problem is that the code for method
"ListOrderedSet.retainAll(Collection<?> coll)" is:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> coll) {
boolean result = collection.retainAll(coll);
....
}
{code}

because "collection.retainAll(coll)" has quadratic complexity if
parameter "coll" is a List. Conceptually, the solution is to call
"coll.retainAll(collection)" which has linear complexity (not
quadratic), because "collection" is always a HashSet (we know this,
because "collection" is an inherited field of ListOrderedSet, and thus
cannot have another type). See the
"java.util.AbstractCollection.retainAll()" code inlined below for why
one call has quadratic complexity, and the other has linear
complexity.

Directly calling "coll.retainAll(collection)" would change the
behavior of ListOrderedSet.retainAll(), which is why the patch seems a
bit involved. In reality, the patch simulates the behavior of
"coll.retainAll(collection)" (which is just the intersection of two
collections). You can easily see this by looking at the patch and at
the "java.util.AbstractCollection.retainAll()" code inlined below.

"collection.retainAll(coll)" is "java.util.HashSet.retainAll()", which
is "java.util.AbstractCollection.retainAll()", which has the code:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> c) {
boolean modified = false;
Iterator<E> e = iterator();
while (e.hasNext()) {
if (!c.contains(e.next())) {
e.remove();
modified = true;
}
}
return modified;
}
{code}

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm if the patch is correct?

Thanks,

Adrian

24/Jan/15 6:06 PM

5 years, 8 weeks ago

255280

No Perforce job exists for this issue.

2

84081

0|i0eqnr:

Commons Collections

COLLECTIONS-427

performance problem in SetUniqueList.retainAll()

Bug

Closed

Major

Fixed

Unassigned

Mert Guldur

24/Jul/12 23:50

27/Nov/15 21:11

27/Jan/15 15:09

3.2.1

4.0-alpha1, 4.0, 4.1

0

2

java 1.6.0_24
Ubuntu 11.10

I am encountering a performance problem in SetUniqueList.retainAll().
It appears in version 3.2.1 and also in revision 1365132. I attached
a test that exposes this problem and a patch that fixes it. On my
machine, for this test, the patch provides a 621X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 6215

The output for the patched version is:
Time is 10

There are two problems here. First, "SetUniqueList.retainAll()"
should have similar implementation with the current implementation of
"ListOrderedSet.retainAll()", which is more optimized. Second, even
"ListOrderedSet.retainAll()" has a performance problem, which was
reported and explained in detail in COLLECTIONS-426.

The attached patch has two parts. The first part (the first loop) is
inspired from COLLECTIONS-426. The second part (everything after the
first loop) is in fact the current implementation of
"ListOrderedSet.retainAll()", with some minor changes to adapt it for
the current code. Overall, the attached patch is very similar to the
COLLECTIONS-426 patch.

I will rehash some of the information from COLLECTIONS-426 (which
describes "ListOrderedSet.retainAll()") for the current
"SetUniqueList.retainAll()".

The current code for "SetUniqueList.retainAll()" is:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> coll) {
boolean result = super.retainAll(coll);
set.retainAll(coll);
return result;
}
{code}

where both "super.retainAll(coll)" and "set.retainAll(coll)" can have
quadratic complexity, e.g., if "coll" is a List. Both these calls to
"retainAll" are in fact calls to
"java.util.AbstractCollection.retainAll()", which has the code:

{code:java|borderStyle=solid}
public boolean retainAll(Collection<?> c) {
boolean modified = false;
Iterator<E> e = iterator();
while (e.hasNext()) {
if (!c.contains(e.next())) {
e.remove();
modified = true;
}
}
return modified;
}
{code}

which iterates over "this" and calls "contains()" on "c". Mapping
this code back to "SetUniqueList.retainAll()" means that the code
iterates over "this" and "set" and calls "contains()" on "coll". If
"coll" has slow "contains()" (e.g., if "coll" is a list), then
"SetUniqueList.retainAll()" has quadratic complexity.

The patch iterates over "coll" and calls "contains()" on "set", which
we know is fast, because "set" is a Set. For a more detailed
discussion of the patch and the problem, see the current
implementation of "ListOrderedSet.retainAll()", the discussion for
COLLECTIONS-426, and the patch for COLLECTIONS-426.

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm if the patch is correct?

24/Jan/15 6:07 PM

5 years, 8 weeks ago

255281

No Perforce job exists for this issue.

2

84082

0|i0eqnz:

Commons Collections

COLLECTIONS-424

Surprising exception by CompositeSet in a situation where CompositeCollection works fine

Bug

Closed

Major

Fixed

Unassigned

Michael Pradel

23/Jul/12 09:07

09/Nov/14 14:31

17/Mar/13 10:03

3.2.1

4.0-alpha1, 4.0

Set

0

3

All environments

We have a method that uses a CompositeCollection. Here's a simplified version of it:

void m(CompositeCollection coll) {
coll.addComposited(new TreeBag());
}

It works fine when the argument is a CompositeCollection, but it throws an exception when the argument is a CompositeSet. E.g.:

m(new CompositeCollection()); // OK
m(new CompositeSet()); // IllegalArgumentException

Although the exception is documented in CompositeSet, this behavior is very surprising. Is there a way to have m() accept CompositeCollections without running into this exception? The only solution that comes to my mind is to dynamically check the type of 'coll' in m(), but this is a rather nasty work-around.

A better solution may be to make the genericity of CompositeCollection explicit by adding a type parameter:

class CompositeCollection<T extends Collection> {
void addComposited(T c) { /* .. */ }
}

class CompositeSet extends CompositeCollection<Set> {
@Override void addComposited(Set c) { /* .. */ }
}

This way, users of CompositeCollection must choose the kind of collections that can be composed and will not encounter surprises, such as the above.

24/Jul/12 4:43 PM

7 years, 1 week, 2 days ago

244856

No Perforce job exists for this issue.

2

32006

0|i05uav:

Commons Collections

COLLECTIONS-423

FastArrayList.toString() fails to check for reference to itself

Bug

Closed

Major

Won't Fix

Unassigned

Michael Pradel

23/Jul/12 09:05

27/Nov/15 21:47

26/Aug/12 21:06

3.2.1

List

0

1

All environments

FastArrayList.toString() throws a StackOverflowError when the list contains itself, because toString() is called recursively. In contrast, ArrayList checks for this case and deals with it appropriately. E.g.:

ArrayList l = new FastArrayList();
l.add(l);
l.toString(); // StackOverflowError

But:

ArrayList l = new ArrayList();
l.add(l);
l.toString(); // OK

To be compatible with its superclass, FastArrayList should also consider this special case.

25/Jul/12 6:59 PM

7 years, 34 weeks, 6 days ago

255282

No Perforce job exists for this issue.

0

84083

0|i0eqo7:

Commons Collections

COLLECTIONS-418

ListUtils.retainAll() is very slow

Bug

Closed

Major

Won't Fix

Unassigned

Adrian Nistor

29/Jun/12 22:16

27/Nov/15 21:47

26/Aug/12 21:32

3.2.1

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in ListUtils.retainAll(). It
appears in version 3.2.1 and also in revision 1355448. I attached a
test that exposes this problem and a one-line patch that fixes it. On
my machine, for this test, the patch provides a 238X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5485

The output for the patched version is:
Time is 23

As the patch shows, the problem is that
"ListUtils.retainAll(Collection<E> collection, Collection<?> retain)"
performs "retain.contains(obj)" for each element in "collection",
which can be very expensive if "retain.contains(obj)" is expensive,
e.g., when "retain" is a list.

The one-line patch I attached puts the elements of "retain" in a
HashSet (which has very fast "contains()"), if "retain" is not already
a set:

"if (!(retain instanceof java.util.Set<?>)) retain = new HashSet<Object>(retain);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

26/Aug/12 9:32 PM

7 years, 30 weeks, 2 days ago

255284

No Perforce job exists for this issue.

2

84085

0|i0eqon:

Commons Collections

COLLECTIONS-417

AbstractLinkedList.retainAll() is very slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

29/Jun/12 22:01

09/Nov/14 14:31

20/Sep/12 18:07

3.2.1

4.0-alpha1, 4.0

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in
AbstractLinkedList.retainAll(). It appears in version 3.2.1 and also
in revision 1355448. I attached a test that exposes this problem and
a one-line patch that fixes it. On my machine, for this test, the
patch provides a 158X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5531

The output for the patched version is:
Time is 35

As the patch shows, the problem is that
"AbstractLinkedList.retainAll(Collection<?> coll)" performs
"coll.contains(it.next())" for each element in the AbstractLinkedList,
which can be very expensive if "coll.contains()" is expensive, e.g.,
when "coll" is a list.

The one-line patch I attached puts the elements of "coll" in a HashSet
(which has very fast "contains()"), if "coll" is not already a set:

"if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

20/Sep/12 6:07 PM

7 years, 26 weeks, 5 days ago

244858

No Perforce job exists for this issue.

3

32008

0|i05ubb:

Commons Collections

COLLECTIONS-415

AbstractLinkedList.removeAll() is very slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

29/Jun/12 21:02

09/Nov/14 14:31

20/Sep/12 18:08

3.2.1

4.0-alpha1, 4.0

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in
AbstractLinkedList.removeAll(). It appears in version 3.2.1 and also
in revision 1355448. I attached a test that exposes this problem and
a one-line patch that fixes it. On my machine, for this test, the
patch provides a 226X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5655

The output for the patched version is:
Time is 25

As the patch shows, the problem is that
"AbstractLinkedList.removeAll(Collection<?> coll)" performs
"coll.contains(it.next())" for each element in the AbstractLinkedList,
which can be very expensive if "coll.contains()" is expensive, e.g.,
when "coll" is a list.

The one-line patch I attached puts the elements of "coll" in a HashSet
(which has very fast "contains()"), if "coll" is not already a set:

"if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

20/Sep/12 6:08 PM

7 years, 26 weeks, 5 days ago

244857

No Perforce job exists for this issue.

3

32007

0|i05ub3:

Commons Collections

COLLECTIONS-416

ListUtils.removeAll() is very slow

Bug

Closed

Major

Won't Fix

Unassigned

Adrian Nistor

29/Jun/12 21:09

27/Nov/15 21:47

25/Jul/12 21:40

3.2.1

0

1

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in ListUtils.removeAll(). It
appears in version 3.2.1 and also in revision 1355448. I attached a
test that exposes this problem and a one-line patch that fixes it. On
my machine, for this test, the patch provides a 217X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5430

The output for the patched version is:
Time is 25

As the patch shows, the problem is that
"ListUtils.removeAll(Collection<E> collection, Collection<?> remove)"
performs "remove.contains(obj)" for each element in "collection",
which can be very expensive if "remove.contains(obj)" is expensive,
e.g., when "remove" is a list.

The one-line patch I attached puts the elements of "remove" in a
HashSet (which has very fast "contains()"), if "remove" is not already
a set:

"if (!(remove instanceof java.util.Set<?>)) remove = new HashSet<Object>(remove);"

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

03/Jul/12 9:50 PM

7 years, 34 weeks, 6 days ago

292943

No Perforce job exists for this issue.

2

164345

0|i0shpb:

Commons Collections

COLLECTIONS-413

Performance problem in DualHashBidiMap

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

21/Jun/12 18:38

09/Nov/14 14:31

23/Jun/12 12:06

3.2.1

4.0-alpha1, 4.0

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in DualHashBidiMap. It
appears in version 3.2.1 and also in revision 1352574 (21 June 2012).
I attached a test that exposes this problem and a patch that fixes it.
On my machine, for this test, the patch provides a 173X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 5029

The output for the patched version is:
Time is 29

The attached test shows that, for a "DualHashBidiMap bidi" object, the
following operation is very slow:

bidi.entrySet().removeAll(toRemove);

DualHashBidiMap.entrySet() returns a
"DualHashBidiMap.EntrySet" object, which inherits
removeAll(Collection<?> coll) from "DualHashBidiMap.View".

As the patch shows, the problem is that
"DualHashBidiMap.View.removeAll(Collection<?> coll)" performs
"coll.contains(it.next())" for each element in the View.
"coll.contains(it.next())" can be very slow, e.g., if "coll" is a
list.

The patch avoids this cost by using remove(Object obj) (defined in
"EntrySet<K, V>", "KeySet<K>", and "Values<V>"), which is fast because
it uses only operations on sets.

Is this a bug, or am I misunderstanding something? If so, can you
please confirm that the patch is correct?

Thanks,

Adrian

23/Jun/12 12:06 PM

7 years, 39 weeks, 3 days ago

292945

No Perforce job exists for this issue.

2

164347

0|i0shpr:

Commons Collections

COLLECTIONS-420

CompositeCollection.containsAll() is very slow

Bug

Closed

Major

Won't Fix

Unassigned

Adrian Nistor

30/Jun/12 01:05

27/Nov/15 21:47

26/Aug/12 21:25

3.2.1

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in
CompositeCollection.containsAll(). It appears in version 3.2.1 and
also in revision 1355448. I attached a test that exposes this problem
and a patch that fixes it. On my machine, for this test, the patch
provides a 167X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 9192

The output for the patched version is:
Time is 54

The problem is that
"CompositeCollection.containsAll(Collection<?> coll)" performs
"contains(item)" for each item in "coll", and "contains(item)"
searches "item" in all collections in CompositeCollection. This can
be very slow if the collections in CompositeCollection have slow
"contains()", e.g., when these collections are lists.

The patch I attached puts the elements in each collection of
CompositeCollection in a HashSet (which has very fast "contains()") if
that collection is not already a set. For efficiency, putting
elements in several HashSet objects is performed lazily in the patch.

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

26/Aug/12 9:25 PM

7 years, 30 weeks, 2 days ago

255283

No Perforce job exists for this issue.

2

84084

0|i0eqof:

Commons Collections

COLLECTIONS-409

ListOrderedSet.addAll() is very slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

19/Jun/12 16:00

09/Nov/14 14:31

19/Jun/12 19:52

3.2.1

4.0-alpha1, 4.0

0

2

COLLECTIONS-407

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in ListOrderedSet.addAll().
It appears in version 3.2.1 and also in revision 1351465 (18 Jun
2012). I have attached a test that exposes this problem and a
three-line patch that fixes it. On my machine, for this test, the
patch provides a 79X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 1837

The output for the patched version is:
Time is 23

As the patch shows, the problem is that
ListOrderedSet.addAll(int index, Collection<? extends E> coll)
performs:
"setOrder.add(index++, e)" for each element in "coll". This is very
expensive, because "setOrder" is an ArrayList, and inserting an
element in the middle of an ArrayList shifts all the elements to the
right.

The patched version avoids this cost by inserting all the elements at
once, thus performing only one insert.

Is this a bug? If so, can you please confirm that the patch is
correct?

Thanks,

Adrian

19/Jun/12 7:52 PM

7 years, 40 weeks ago

292949

No Perforce job exists for this issue.

2

164351

0|i0shqn:

Commons Collections

COLLECTIONS-524

ListOrderedSet can have duplicates

Bug

Closed

Major

Fixed

Unassigned

J Goodfellow

06/May/14 00:58

27/Nov/15 21:11

06/May/14 22:14

3.2.1, 4.0

4.1

0

1

tomcat 7, linux

The static method, org.apache.commons.collections.set.ListOrderedSet.decorate(List list), has a comment "If the list contains duplicates, the duplicates are removed". It does not remove duplicates and will leave you in an inconsistent state if your list has duplicates. (i.e. the .size() result is smaller than the number of iterations from the iterator)

06/May/14 10:13 PM

5 years, 46 weeks ago

390786

No Perforce job exists for this issue.

0

391026

0|i1vb5z:

Commons Collections

COLLECTIONS-487

CollectionUtils.removeAll is not work as expected

Bug

Closed

Blocker

Duplicate

Unassigned

Cooper

21/Oct/13 07:48

09/Nov/14 14:31

21/Oct/13 07:56

3.2.1

4.0

Collection, List

0

1

360

0%

COLLECTIONS-219

JDK 1.6

http://svn.apache.org/viewvc/commons/proper/collections/tags/COLLECTIONS_3_2_1/src/java/org/apache/commons/collections/CollectionUtils.java?revision=1211567&view=markup

Line: 1122
Problem:
The method called "removeAll", but call "retainAll" internally.

0%

360

21/Oct/13 7:55 AM

6 years, 22 weeks, 1 day ago

354363

No Perforce job exists for this issue.

0

354653

0|i1p3cf:

Commons Collections

COLLECTIONS-536

(Code style) map.size() call in MapUtils.putAll()

Bug

Closed

Trivial

Fixed

Unassigned

Tagir Valeev

29/Oct/14 02:58

27/Nov/15 21:11

29/Oct/14 21:05

3.2.1, 4.0

4.1

Map

0

1

Any

In class org.apache.commons.collections(4).MapUtils there's a method putAll(final Map<K, V> map, final Object[] array) which starts with
{noformat}
map.size(); // force NPE
{noformat}

Actually map.size() is not that harmless call for any map. For example, consider java.util.concurrent.ConcurrentHashMap size() implementation: depending on the circumstances it may take even more time than the rest of the putAll method (at least prior to JDK 8). Things are even worse for ConcurrentSkipListMap: its size() method iterates over all the map elements. Thus I'd suggest to replace this call with more conventional check like:
{noformat}
if(map == null) {
throw new NullPointerException();
}
{noformat}

If you still want to save bytes, you may use {{map.getClass()}}. It's final, so it will never be overridden to do something strange and it's even used by JavaC for the same purpose (to trigger NPE). For example, if you compile and disassemble this code:
{noformat}
public class Outer {
public class Inner {}
public void test(Outer n) { n.new Inner(); }
}
{noformat}
You will see a getClass() call which is used to trigger NPE.

performance

29/Oct/14 9:05 PM

5 years, 20 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i21pc7:

Commons Collections

COLLECTIONS-394

FastTreeMap is not compatible with TreeMap

Bug

Closed

Major

Won't Fix

Unassigned

Michael Pradel

29/Feb/12 14:49

27/Nov/15 21:47

23/Jun/12 17:14

3.2.1

Map

0

1

all

FastTreeMap extends TreeMap in a way that doesn't preserve the superclass behavior. For example, the following code prints 'null', but I would expect it to print '1=1', which is what TreeMap does:

TreeMap map = new FastTreeMap();
//TreeMap map = new TreeMap();

map.put(1, "1");
map.put(3, "3");

Entry e = map.floorEntry(2);
System.out.println(e);

This behavior is surprising and can hit you every time a reference of type TreeMap refers to an instance of FastTreeMap. A subclass instance used through a superclass interface shouldn't change the visible behavior of its superclass.

The reason for this problem seems to be that FastTreeMap both extends TreeMap and delegates to a TreeMap via the 'map' field. I.e., there are two map instances for a single FastTreeMap instance.

29/Feb/12 2:51 PM

7 years, 39 weeks, 3 days ago

229815

No Perforce job exists for this issue.

0

164361

0|i0shsv:

Commons Collections

COLLECTIONS-387

CollectionUtils.removeAll does retain instead of remove

Bug

Closed

Major

Duplicate

Unassigned

Taras Pushyk

27/Dec/11 12:34

28/Feb/13 20:02

27/Dec/11 12:35

3.2.1

4.0

Collection

0

org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection) method calls org.apache.commons.collections.ListUtils.retainAll(Collection, Collection) instead of org.apache.commons.collections.ListUtils.removeAll(Collection, Collection).

bug, removeAll

8 years, 13 weeks ago

222100

No Perforce job exists for this issue.

0

164368

0|i0shuf:

Commons Collections

COLLECTIONS-386

CollectionUtils.removeAll(Collection, Collection) has an CopyPaste-Failure

Bug

Closed

Critical

Duplicate

Joerg Schaible

Steininger Thomas

03/Nov/11 14:07

03/Nov/11 16:19

3.2.1

4.0, Nightly Builds

0

1

COLLECTIONS-357

commons-collections-3.2.1.jar

public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}

03/Nov/11 2:09 PM

8 years, 20 weeks, 5 days ago

215909

No Perforce job exists for this issue.

0

164369

0|i0shun:

Commons Collections

COLLECTIONS-690

Source code compilation error

Bug

Resolved

Major

Won't Fix

Unassigned

Jayanth G H

20/Jul/18 05:13

18/Mar/20 02:55

20/Jul/18 08:56

3.2.2

Collection

0

1

Windows 10
JDK 1.8

# Took source code from "https://github.com/apache/commons-collections/tree/collections-3.2.2"
# Trying to compile the code using "ant compile" in command prompt
# Got the compilation error. Error logs is attached.

20/Jul/18 8:56 AM

1 year, 34 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

Important

0|i3w3lj:

Commons Collections

COLLECTIONS-712

ExtendedProperties.save swallows instead of throws IOException

Bug

Closed

Trivial

Won't Fix

Unassigned

Philip Hodges

18/Mar/19 13:39

05/Jul/19 17:23

05/Jul/19 15:31

3.2.2

Properties

0

1

commons-collections-3.2.2-src/src/java/org/apache/commons/collections/ExtendedProperties.java

/**
* Save the properties to the given output stream.
* ...
* @throws IOException if an IO error occurs - no it does not.
*/
public synchronized void save(OutputStream output, String header) throws IOException {
...
PrintWriter theWrtr = new PrintWriter(output);
...
// theWrter.flush();
// missing: if (theWrtr.checkError()) throw new IOException();

Impact: caller cannot tell if the properties were completely saved, perhaps the disk filled up instead. Missing checkError is an antipattern for PrintWriter and PrintStream.

05/Jul/19 3:31 PM

36 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z00tgo:

Commons Collections

COLLECTIONS-701

StackOverflowError in SetUniqueList.add() when it receives itself

Bug

Resolved

Critical

Fixed

Unassigned

Shin Hong

31/Oct/18 12:38

23/Nov/18 07:32

3.2.2

4.3

Collection

0

5

Hi.

We found that the following test case fails with a StackOverFlowError exception:
{code:java}
test() {
SetUniqueList l = new SetUniqueList(new LinkedList<Object>()) ;
l.add((Object) l) ;
}{code}
The add() execution traps into an infinite recursion which crashes the program.

From the stack trace, we found that the infinite recursion occurs

at AbstractList.hashCode() since it invokes hashCode() of each of its elements.

31/Oct/18 3:07 PM

1 year, 16 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Important

0|i3zucv:

Commons Collections

COLLECTIONS-596

FileInputStream is not closed

Bug

Resolved

Major

Won't Fix

Unassigned

Kaloyan Spiridonov

30/Sep/16 13:36

24/May/17 08:34

3.2.2

0

2

In ExtendedProperties class on 602 line the function load is called with input stream. I do not see anywhere stream to be closed. Is there any reason for that?

24/May/17 8:34 AM

2 years, 42 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i34avr:

Commons Collections

COLLECTIONS-585

When use commons collection 3.2.2, show "JavaSE not found"

Bug

Open

Minor

Unresolved

Unassigned

neal zhang11

29/Jan/16 02:53

18/Mar/20 02:08

04/Nov/19 03:07

3.2.2

Collection

0

3

jdk1.7 commons-collections 3.2.2

Hi all, when i use commons-collections 3.2.2, and build my rcp application. it always show this error:
[java] [eclipse.generateFeature] Some inter-plug-in dependencies have not been satisfied.
[java] [eclipse.generateFeature] Bundle org.apache.commons.collections:
[java] [eclipse.generateFeature] Host plug-in JavaSE_0.0.0 has not been found.

but for commons-collections 3.2.1.every thing is fine.
and compared the 3.2.2 and 3.2.1
Mainfest.mf file add this:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.3))"
if remove it, i can build my application.
i use jdk1.7 in my local(i also tested jdk1.8, same problem)
so i don't understand why show this problem.
i am new guy for this, if misunderstand this, sorry

24/May/17 8:56 AM

19 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2s4lr:

Commons Collections

COLLECTIONS-582

Maven repository metadata of Commons Collections in bad condition

Bug

Closed

Major

Won't Fix

Unassigned

Alexander Veit

18/Nov/15 08:00

27/Nov/15 21:47

18/Nov/15 08:05

3.2.2

Core

0

2

The metadata located at

https://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml

are in a bad condition.

It states that latest version and release version is 20040616. Moreover, the list of versions does not reflect the actual release order.

This makes it difficult to automatically check for new versions in our QA processes.

18/Nov/15 8:05 AM

4 years, 17 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2okcf:

Commons Collections

COLLECTIONS-482

Transformed* classes require double the number of generic qualifiers

Bug

Closed

Major

Duplicate

Unassigned

Hollis Waite

10/Sep/13 18:16

18/Mar/20 02:58

27/Nov/15 21:47

10/Sep/13 19:55

4.0-alpha1

Bag, Collection, List, Map, Set

0

1

COLLECTIONS-333

Transformed* classes currently have the same number of generic qualifiers as their parent interfaces (e.g. one for TransformedList and two for TransformedMap). In order to handle transformations between different types, transforming collections should specify both input and output classes.

10/Sep/13 7:55 PM

6 years, 28 weeks ago

347799

No Perforce job exists for this issue.

0

348098

0|i1nz13:

Commons Collections

COLLECTIONS-475

Wrong timeout handling in expiration policies of PassiveExpiringMap

Bug

Closed

Minor

Fixed

Unassigned

Thomas Neidhart

02/Jul/13 21:04

09/Nov/14 14:31

14/Jul/13 19:09

4.0-alpha1

4.0

0

The timeunit parameter in the ctor of ConstantTimeToLiveExpirationPolicy is not used.

Additionally, the validateAndConvertToMillis method is wrong, it should be changed like this:

{noformat}
private static long validateAndConvertToMillis(final long timeToLive,
final TimeUnit timeUnit) {
if (timeUnit == null) {
throw new IllegalArgumentException("Time unit must not be null");
}
return TimeUnit.MILLISECONDS.convert(timeToLive, timeUnit);
}
{noformat}

6 years, 36 weeks, 2 days ago

336120

No Perforce job exists for this issue.

0

336444

0|i1lz7z:

Commons Collections

COLLECTIONS-498

CollectionBag should respect removeAll / retainAll contract of decorated bags

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

11/Nov/13 19:46

09/Nov/14 14:31

11/Nov/13 20:29

4.0-alpha1

4.0

0

In case the decorated collection does not support removal, i.e. throws an UnsupportedOperationException, CollectionBag does not respect this in case a null argument was specified.

To be consistent with the testing framework, CollectionBag shall delegate the call to the decorated collection in such cases.

6 years, 19 weeks, 1 day ago

358017

No Perforce job exists for this issue.

0

358307

0|i1ppuv:

Commons Collections

COLLECTIONS-501

Rename MultiKeyMap.remove(K key1, K key2) to avoid clashes with newly introduced default methods in Java 8

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

17/Nov/13 16:04

09/Nov/14 14:31

17/Nov/13 18:31

4.0-alpha1

4.0

0

Java 8 will introduce new default methods for the Map interface which clash with the existing method "V remove(K key1, K key2)" in our MultiKeyMap interface.

To avoid future problems rename the method (and other similar methods with more multi key arguments) to a more specific version:

* V removeMultiKey(K key1, K key2, ...)
* V removeKey(K key1, K key2, ...)

6 years, 18 weeks, 2 days ago

358997

No Perforce job exists for this issue.

0

359287

0|i1pvwf:

Commons Collections

COLLECTIONS-500

Rename MultiMap.remove(K, V) to avoid clashes with newly introduced default methods in Java 8

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

17/Nov/13 16:02

09/Nov/14 14:31

17/Nov/13 17:10

4.0-alpha1

4.0

0

Java 8 will introduce new default methods for the Map interface which clash with the existing method "V remove(K key, V value)" in our MultiMap interface.

To avoid future problems rename the method to a more specific version and change the return type to be more logical. Brief discussion on the ml favored either:

* boolean removeMapping(K key, V value)
* boolean removeValue(K key, V value)

6 years, 18 weeks, 2 days ago

358996

No Perforce job exists for this issue.

0

359286

0|i1pvw7:

Commons Collections

COLLECTIONS-496

UnmodifiableBoundedCollection does not implement Unmodifiable marker interface

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

11/Nov/13 16:42

09/Nov/14 14:31

11/Nov/13 16:47

4.0-alpha1

4.0

0

The UnmodifiableBoundedCollection does not implement the Unmodifiable interface.

6 years, 19 weeks, 1 day ago

357969

No Perforce job exists for this issue.

0

358259

0|i1ppk7:

Commons Collections

COLLECTIONS-495

UnmodifiableTrie should not decorate an already unmodifiable Trie

Bug

Closed

Minor

Fixed

Unassigned

Thomas Neidhart

11/Nov/13 16:25

09/Nov/14 14:31

11/Nov/13 16:30

4.0-alpha1

4.0

0

An already unmodifiable trie was decorated again.
To be consistent with the other Unmodifiable wrappers, in this case the object itself shall be returned.

Also the return type shall be changed to Trie.

6 years, 19 weeks, 1 day ago

357967

No Perforce job exists for this issue.

0

358257

0|i1ppjr:

Commons Collections

COLLECTIONS-597

Correction of Javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure

Bug

Resolved

Trivial

Fixed

Gary D. Gregory

Enrique

20/Oct/16 13:47

18/Mar/20 02:58

21/Oct/16 05:53

4.0, 4.1

4.2

Functor

0

2

300

0%

Correct the javadoc for org.apache.commons.collections4.functors.CatchAndRethrowClosure, replacing:
CollctionUtils.forAllDo(strList, writer);
by:
CollectionUtils.forAllDo(strList, writer);

0%

300

documentation

21/Oct/16 5:53 AM

3 years, 21 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i355kf:

Commons Collections

COLLECTIONS-553

TransformedMultiValuedMap.equals() fails when comparing the value with itself

Bug

Closed

Major

Fixed

Unassigned

M Kim

16/Feb/15 16:09

27/Nov/15 21:11

07/Apr/15 11:41

4.0

4.1

Map

0

1

COLLECTIONS-543

TransformedMultiValuedMap.equals() does not return true when comparing a value of a Collection key with itself. Is it allowed to put Collection as a key in TransformedMultiValuedMap at all? If not, I think it should be specified in the document. Or, equals() should be fixed accordingly.

Reproduce step
{code:title=Test.java|borderStyle=solid}
public void test()
{
TransformedMultiValuedMap map = TransformedMultiValuedMap.transformingMap((MultiValuedMap)new MultiValuedHashMap(),TransformerUtils.stringValueTransformer(), TransformerUtils.stringValueTransformer());

MultiValuedHashMap helperMap = new MultiValuedHashMap();
helperMap.put("KEY", "Value");
Collection key = helperMap.keySet();
map.put(key, "Hi");
Collection value = map.get(key);
assertTrue("Contract failed: value.equals(value)", value.equals(value));
}
{code}

07/Apr/15 11:41 AM

4 years, 50 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i25onj:

Commons Collections

COLLECTIONS-545

Undocumented performance issue in the removeAll method in CollectionUtils

Bug

Closed

Trivial

Fixed

Unassigned

Oswaldo Olivo

12/Jan/15 06:04

27/Nov/15 21:11

23/Jan/15 09:34

4.0

4.1

Collection

0

1

Ubuntu 14.04

This bug is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-544

The method removeAll in CollectionUtils is inefficient when the second parameter collection has a slow containment method.

The following is the current implementation with its documentation:
============================
/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a collection containing all the elements in <code>c</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.removeAll(remove);</code>.
*
* @param <E> the type of object the {@link Collection} contains
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>Collection</code> containing all the elements of <code>collection</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since 4.0 (method existed in 3.2 but was completely broken)
*/
public static <E> Collection<E> removeAll(final Collection<E> collection, final Collection<?> remove) {
return ListUtils.removeAll(collection, remove);
}

=======================================

We can notice the inefficiency by looking at the removeAll method in ListUtils.
The removeAll method from ListUtils is implemented and documented as follows:

=======================================

/**
* Removes the elements in <code>remove</code> from <code>collection</code>. That is, this
* method returns a list containing all the elements in <code>collection</code>
* that are not in <code>remove</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>remove</code> contains <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* <code>collection</code> and thus cannot call <code>collection.removeAll(remove);</code>.
* 
* This implementation iterates over <code>collection</code>, checking each element in
* turn to see if it's contained in <code>remove</code>. If it's not contained, it's added
* to the returned list. As a consequence, it is advised to use a collection type for
* <code>remove</code> that provides a fast (e.g. O(1)) implementation of
* {@link Collection#contains(Object)}.
*
* @param <E> the element type
* @param collection the collection from which items are removed (in the returned collection)
* @param remove the items to be removed from the returned <code>collection</code>
* @return a <code>List</code> containing all the elements of <code>c</code> except
* any elements that also occur in <code>remove</code>.
* @throws NullPointerException if either parameter is null
* @since 3.2
*/
public static <E> List<E> removeAll(final Collection<E> collection, final Collection<?> remove) {
final List<E> list = new ArrayList<E>();
for (final E obj : collection) {
if (!remove.contains(obj)) {
list.add(obj);
}
}
return list;
}

=======================================

In the case of ListUtils:removeAll, the inefficiency is properly documented.

Perhaps the disclaimer about potential inefficiencies depending on the type
of the parameter collection in ListUtils:removeAll should also be included in CollectionUtils:removeAll.

Collections, documentaion, performance

23/Jan/15 9:34 AM

5 years, 8 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i248xr:

Commons Collections

COLLECTIONS-548

Performance issue in CompositeCollection::retainAll

Bug

Closed

Minor

Won't Fix

Unassigned

Oswaldo Olivo

21/Jan/15 21:50

27/Nov/15 21:47

24/Jan/15 12:59

4.0

Collection

0

1

Ubuntu 14.04

There seems to be a performance problem with the function retainAll of
CompositeCollection. This is analogous to https://issues.apache.org/jira/browse/COLLECTIONS-534 .

The following is the code of the function:

{code}

/**
* Retains all the elements in the specified collection in this composite collection,
* removing all others.
* 
* This implementation calls <code>retainAll()</code> on each collection.
*
* @param coll the collection to remove
* @return true if the collection was modified
* @throws UnsupportedOperationException if retainAll is unsupported
*/
public boolean retainAll(final Collection<?> coll) {
boolean changed = false;
for (final Collection<E> item : all) {
changed |= item.retainAll(coll);
}
return changed;
}

{code}

The performance problem occurs when the underlying collections in the current collection have a slow retainAll method. Whenever we're relying on Collection::retainAll, slow cases tend to occur when the parameter collection has a slow contains method.

The following test harness shows the performance degradation between
using a list and using a set as a parameter, across different collection sizes.

{code}
public static void compositeCollectionRetainAllTest(boolean original) {

int N=500000;

ArrayList<Integer> firstArrayList=new ArrayList<Integer>();
ArrayList<Integer> secondArrayList=new ArrayList<Integer>();

for(int i=0;i<N;++i) {

firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer(N-1-i));

}
CompositeCollection col = new CompositeCollection(firstArrayList);

col.retainAll(original ? secondArrayList : (new HashSet<Integer>(secondArrayList)));

}

{code}

In the following table "Original" corresponds to the time taken by
the existing implementation of CompositeCollection::retainAll, "Repaired" to the time taken by the function invoked with the parameter converted into a set, and "Speed-up" to the speed-up obtained after the repair.

N Original(s) Repaired(s) Speed-up(X)

10 1.04 1.04 1.00
100 1.04 1.05 0.99
1000 1.06 1.06 1.00
10000 1.12 1.10 1.01
100000 9.34 1.15 8.12
500000 > 300 1.29 > 232.55

If it's unacceptable to convert the parameter into a set before calling
retainsAll, a solution would be to include a warning to the user in the documentation that the parameter should have a fast contains method when possible.

performance

24/Jan/15 12:59 PM

5 years, 8 weeks, 3 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i24n0n:

Commons Collections

COLLECTIONS-547

Performance issue in SetUtils::isEqualSet

Bug

Closed

Minor

Not A Problem

Unassigned

Oswaldo Olivo

21/Jan/15 21:10

27/Nov/15 21:47

22/Jan/15 09:18

4.0

Set

0

1

Ubuntu 14.04

There seems to be a performance problem with the function isEqualSet of
SetUtils when the first parameter is of a collection type that has a slow containsAll/contains method.

The following is the code of the function:

{code}
/**
* Tests two sets for equality as per the <code>equals()</code> contract
* in {@link java.util.Set#equals(java.lang.Object)}.
* 
* This method is useful for implementing <code>Set</code> when you cannot
* extend AbstractSet. The method takes Collection instances to enable other
* collection types to use the Set implementation algorithm.
* 
* The relevant text (slightly paraphrased as this is a static method) is:
* <blockquote>
* Two sets are considered equal if they have
* the same size, and every member of the first set is contained in
* the second. This ensures that the <tt>equals</tt> method works
* properly across different implementations of the <tt>Set</tt>
* interface.
*
* 
* This implementation first checks if the two sets are the same object:
* if so it returns <tt>true</tt>. Then, it checks if the two sets are
* identical in size; if not, it returns false. If so, it returns
* <tt>a.containsAll((Collection) b)</tt>.
* </blockquote>
*
* @see java.util.Set
* @param set1 the first set, may be null
* @param set2 the second set, may be null
* @return whether the sets are equal by value comparison
*/
public static boolean isEqualSet(final Collection<?> set1, final Collection<?> set2) {
if (set1 == set2) {
return true;
}
if (set1 == null || set2 == null || set1.size() != set2.size()) {
return false;
}

return set1.containsAll(set2);
}

{code}

The problem is that in the last return statement, the function relies on the
containsAll method of the class of the set1, which can be any type of collection.

The following test harness shows the performance degradation between
using a list and using a set as a first parameter, across different collection sizes.

{code}
public static void setUtilsisEqualSetTest(boolean original) {

int N=500000;
ArrayList<Integer> firstArrayList=new ArrayList<Integer>();
ArrayList<Integer> secondArrayList=new ArrayList<Integer>();
for(int i=0;i<N;++i) {

firstArrayList.add(new Integer(i));
secondArrayList.add(new Integer((N-1)-i));

}

SetUtils.isEqualSet(original?firstArrayList:(new HashSet<Integer>(firstArrayList)),secondArrayList);

{code}

In the following table "Original" corresponds to the time taken by
the existing implementation of SetUtils::isEqualSet, "Repaired" to the time
taken by the function invoked with the first parameter converted into a
set, and "Speed-up" to the speed-up obtained after the repair.

N Original(s) Repaired(s) Speed-up(X)

10 1.01 1.02 0.99
100 1.02 1.02 1
1000 1.04 1.04 1
10000 1.15 1.09 1.05
100000 9.33 1.11 8.40
500000 > 300 1.26 > 238.09

One way to deal with this would be to call the CollectionUtils::containsAll method instead of Collection::containsAll, since it has a linear time implementation instead of quadratic, and can handle the types of isEqualSet.

Another solution would be to include a warning to the user in the documentation that the first parameter should have a fast containment method when possible.

perfomance

22/Jan/15 9:18 AM

5 years, 8 weeks, 5 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i24mx3:

Commons Collections

COLLECTIONS-543

AbstractCollectionDecorator should not delegate equals and hashcode

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

07/Jan/15 22:05

27/Nov/15 21:11

12/Jan/15 15:21

4.0

4.1

0

COLLECTIONS-512, COLLECTIONS-553

In order to preserve the symmetry of equals the AbstractCollectionDecorator shall not forward calls to equals and hashcode to the decorated collection.

The test for equality usually also includes a test for the specific interface, e.g. List, which the collection decorator does not implement.

The relevant sub-classes like AbstractListDecorator can delegate the calls to safely fulfill the Collections contract.

5 years, 10 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i241uf:

Commons Collections

COLLECTIONS-531

Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection, Collection, Equator) may throw ClassCastException in certain cases

Bug

Closed

Minor

Fixed

Unassigned

Dipanjan Laha

27/May/14 10:13

27/Nov/15 21:11

29/May/14 18:34

4.0

4.1

Collection

0

1

CollectionUtils#isEqualCollection(Collection, Collection, Equator) is defined as
{code}
public static boolean isEqualCollection(final Collection<?> a, final Collection<?> b, final Equator<?> equator) {
...
}
{code}

This makes it possible to invoke it with a code like
{code}
public static class IntegerEquator implements Equator<Integer> {
public boolean equate(Integer o1, Integer o2) {
return o1.intValue() == o2.intValue();
}
public int hash(Integer o) {
return o.intValue();
}
}

@Test
public void test() {
List<Long> longList = Arrays.asList(1L, 2L);
List<Integer> intList = Arrays.asList(1, 2);
assertTrue(CollectionUtils.isEqualCollection(longList, intList, new IntegerEquator()));

}
{code}
which compiles perfectly but throws a ClassCastException as Long cannot be cast to an Integer. However, the generics should be defined such that this is stopped at compile time itself.

If we modify the method to something like
{code}
public static <E> boolean isEqualCollection(final Collection<? extends E> a, final Collection<? extends E> b, final Equator<? super E> equator) {
...
}
{code}
the above example would give a compile time error. imho we should modify this method with bounded wildcards. I don't think this change would break any existing binaries if the method is being used correctly, otherwise it is probably throwing ClassCastExceptions anyway.

Test case attached

29/May/14 6:34 PM

5 years, 42 weeks, 5 days ago

394974

No Perforce job exists for this issue.

1

395109

0|i1w06v:

Commons Collections

COLLECTIONS-592

Deletions/insertions get lost in the ReplacementsFinder if they're at the end of the compared sequences

Bug

Open

Minor

Unresolved

Unassigned

Alexis Mestag

19/Jun/16 22:19

18/Mar/20 02:08

20/Jun/16 07:31

4.0, 4.1

0

1

In the {{sequence}} package, when comparing 2 lists with a {{SequencesComparator}} and visiting the {{EditScript}} with a {{ReplacementsFinder}}, pending deletions and insertions get lost in the {{ReplacementsFinder}} when they're at the end of the sequences.

The {{ReplacementsFinder}} stores the deletions and insertions until it encounters a {{KeepCommand}}, when it flushes the pending commands by triggering the {{handleReplacement}} method of its {{ReplacementHandler}}.

The problem is, when edit commands are at the end of the sequences, the {{ReplacementsFinder}} will never encounter a {{KeepCommand}} to flush them, so they're stuck here and will never be handed over the {{ReplacementHandler}}.

To fix this behavior in client code, one can manually call {{ReplacementsFinder.visitKeepCommand(null)}} after the {{EditScript.visit()}} call.

I patched this bug in the library by adding a {{CommandVisitor.endOfVisit}} method and calling it at the end of the {{EditScript.visit}} method, so it allows to flush the pending deletions/insertions in the {{ReplacementsFinder}} when the end of the {{EditScript}} is reached.

3 years, 39 weeks, 2 days ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

Patch

0|i2zpnr:

Commons Collections

COLLECTIONS-577

PatriciaTrie bugs when only a few bits change

Bug

Closed

Critical

Duplicate

Unassigned

Chris Duncan

25/Sep/15 22:27

27/Nov/15 21:47

28/Sep/15 09:45

4.0

4.1

Map

0

1

I have a bug report for you, for the class AbstractPatriciaTrie.
It has to do with how you handle bits when they are very close to each other.
For example, some of your methods seem to think that if the only difference between a prefix and a longer string, is a single additional bit, then they are actually the same data. Or if the only difference is some number of zero bits, then it also thinks they are the same data.
There are also MANY situations where the prefixMap does not return all the strings that start with the prefix.

Can you also make AbstractPatriciaTrie public, and your other package level methods into protected level, that way I don't have to copy the entire class and subclasse's code out into another class just to extend it?

thank you,
Chris Duncan (github user: VEQRYN)

25/Sep/15 10:47 PM

4 years, 25 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2ll0f:

Commons Collections

COLLECTIONS-579

PassiveExpiringMap doesn't work when the key is a byte array

Bug

Closed

Major

Invalid

Unassigned

Roger R Andrews

04/Nov/15 12:48

27/Nov/15 21:47

04/Nov/15 13:19

4.0

Map

0

1

GNU/Linux Ubuntu 15.10 64 bits, OpenJDK 1.8.0_65

When you put a (key,value) pair in a PassiveExpiringMap and the key is byte[] you can't retrieve it.

Code to reproduce the problem:

byte[] key = {0,0,0,1};
PassiveExpiringMap<byte[],byte[]> map = new PassiveExpiringMap<byte[],byte[]> ();
map.put(key,key);

byte[] queryKey = {0,0,0,1};
//this should be true
map.containsKey(queryKey) == false

04/Nov/15 1:19 PM

4 years, 19 weeks, 5 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Important

0|i2nxsf:

Commons Collections

COLLECTIONS-516

NullPointerException in MapUtils.toProperties

Bug

Closed

Major

Fixed

Unassigned

Cyrille Artho

10/Apr/14 04:39

27/Nov/15 21:11

19/May/14 20:38

4.0

4.1

Collection

0

1

Mac OS 10.9, Java 6

calling MapUtils.toProperties with a map having null entries results in a NullPointerException. In this case the Map has only entry <null, null>.

However, javadoc states "A null input will return an empty
properties object." so (1) this should be clarified as it would
only apply to the map reference itself, not its contents, or (2)
an empty property object should be generated for null entries in
the map as well.

10/Apr/14 8:38 PM

5 years, 44 weeks, 1 day ago

385961

No Perforce job exists for this issue.

1

386225

0|i1uhnb:

Commons Collections

COLLECTIONS-515

ClassCastException in LazySortedMap when used with equals/transformers

Bug

Closed

Major

Invalid

Unassigned

Cyrille Artho

10/Apr/14 04:36

27/Nov/15 21:47

10/Apr/14 20:46

4.0

Collection, Map

0

1

Mac OS 10.9, Java 6

When LazySortedMap is used by equals, the result is
java.lang.ClassCastException: org.apache.commons.collections4.map.LazySortedMap cannot be cast to java.lang.String

This seems to be odd, as the use of the different transformations should not result in internal casting to String. See the attached unit test to reproduce.

10/Apr/14 8:46 PM

5 years, 49 weeks, 5 days ago

385960

No Perforce job exists for this issue.

1

386224

0|i1uhn3:

Commons Collections

COLLECTIONS-514

NullPointerException in MapBackedSet.mapBackedSet

Bug

Closed

Major

Invalid

Unassigned

Cyrille Artho

10/Apr/14 04:31

27/Nov/15 21:47

10/Apr/14 20:59

4.0

Bag, Collection, Set

0

1

MacOS 10.9, Java 6

It seems that addAll has issues with adding a set that is backed by a singleton map with entry null -> null. However, the javadoc of the involved classes does not state that null entries are disallowed.
Either the code should allow adding a null entry to a bag, or the documentation should state that null entries are not allowed.

See the attached unit test in JUnit format to reproduce the problem.

10/Apr/14 8:59 PM

5 years, 49 weeks, 5 days ago

385959

No Perforce job exists for this issue.

1

386223

0|i1uhmv:

Commons Collections

COLLECTIONS-513

NullPointerException in SwitchTransformer.transform

Bug

Closed

Major

Invalid

Unassigned

Cyrille Artho

10/Apr/14 02:00

27/Nov/15 21:47

10/Apr/14 20:28

4.0

Functor

0

1

Mac OS 10.9, Java 6 and Java 7

A relatively complex test case generated by Randoop results in a NullPointerException in SwitchTransformer.transform.

I'm not sure if this is an incorrect usage of the method, or if it is a real bug.

10/Apr/14 8:28 PM

5 years, 49 weeks, 5 days ago

385946

No Perforce job exists for this issue.

1

386210

0|i1uhjz:

Commons Collections

COLLECTIONS-512

equals/hashCode mismatch

Bug

Closed

Major

Fixed

Unassigned

Cyrille Artho

10/Apr/14 01:56

27/Nov/15 21:11

02/Jan/15 13:03

4.0

4.1

Collection, Comparator

0

2

COLLECTIONS-543

Mac OS 10.9, Java 6 and Java 7

We used Randoop on the collection classes, which found several test cases where two objects are equal but their hash code differs.

I will attach a file containing two test cases that are different; the other tests seem to be longer versions showing the same issue.

10/Apr/14 9:55 PM

5 years, 11 weeks, 4 days ago

385944

No Perforce job exists for this issue.

2

386208

0|i1uhjj:

Commons Collections

COLLECTIONS-518

AbstractIterableGetMapDecorator should be abstract

Bug

Reopened

Minor

Unresolved

Unassigned

Dipanjan Laha

14/Apr/14 05:36

31/May/15 18:52

4.0

5.0

Map

0

1

AbstractIterableGetMapDecorator should be abstract, but is not

06/May/14 9:01 PM

4 years, 42 weeks, 2 days ago

386509

No Perforce job exists for this issue.

1

386773

0|i1ul0n:

Commons Collections

COLLECTIONS-509

Clarify javadoc of CollectionBag

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

08/Mar/14 18:45

27/Nov/15 21:11

08/Mar/14 18:47

4.0

4.1

0

The javadoc of CollectionBag should clarify which methods have changed wrt the original Bag interface.

6 years, 2 weeks, 3 days ago

377975

No Perforce job exists for this issue.

0

378267

0|i1t4of:

Commons Collections

COLLECTIONS-507

ComparatorUtils.chainedComparator(..) should not force the objects to implement Comparable

Bug

Closed

Major

Fixed

Unassigned

Gerson

12/Feb/14 20:29

27/Nov/15 21:11

12/Feb/14 21:18

4.0

4.1

Comparator

0

1

12/Feb/14 9:18 PM

6 years, 5 weeks, 6 days ago

373338

No Perforce job exists for this issue.

0

373639

0|i1sc6n:

Commons Collections

COLLECTIONS-474

Exception in ListOrderedMap#putAll if map contains null values

Bug

Closed

Major

Fixed

Unassigned

Ning Chen

24/Jun/13 18:22

18/Mar/20 02:15

09/Nov/14 14:31

30/Jun/13 20:10

4.0

4.0-alpha1, 4.0

Map

0

1

java 1.7.0_09

Dear apache developers, thanks for the great project. Recently, I encountered an IndexOutOfBoundsException in ListOrderedMap in the latest revision (r1495998) with the crash stack trace:
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 2, Size: 1
at java.util.ArrayList.add(ArrayList.java:367)
at org.apache.commons.collections4.map.ListOrderedMap.put(ListOrderedMap.java:448)
at org.apache.commons.collections4.map.ListOrderedMap.putAll(ListOrderedMap.java:246)
at Test.main(Test.java:15)

I've also attached a test case that can reproduce this crash.

I think this test case actually reveals the bug reported in COLLECTIONS-411 (https://issues.apache.org/jira/browse/COLLECTIONS-411). However, it seems that the original patch for COLLECTIONS-411 missed a corner case.

Could you please check if this is indeed a bug? Thanks!

24/Jun/13 6:55 PM

6 years, 38 weeks, 2 days ago

334836

No Perforce job exists for this issue.

1

335160

0|i1lrbb:

Commons Collections

COLLECTIONS-566

IteratorUtils.collatedIterator do not use natural ordering if no comparator was provided

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

04/Jun/15 20:19

27/Nov/15 21:11

04/Jun/15 20:36

4.0

4.1

0

In case a null comparator was provided natural ordering should be used, as stated in the javadoc.

In fact an exception is thrown the first time the returned iterator is used.

4 years, 41 weeks, 5 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2fnj3:

Commons Collections

COLLECTIONS-570

All decorators shall throw a NullPointerException if the decorated argument is null

Bug

Closed

Minor

Fixed

Unassigned

Thomas Neidhart

22/Jun/15 09:50

27/Nov/15 21:11

22/Jun/15 13:02

4.0

4.1

0

To be consistent, the constructor shall throw a NullPointerException instead of a IllegalArgumentException if the argument is null.

4 years, 39 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2gbtb:

Commons Collections

COLLECTIONS-559

Objects which are not of type V can be placed in a MultiValueMap<K,V>.

Bug

Closed

Major

Invalid

Unassigned

Pétur Ingi Egilsson

01/Apr/15 19:26

01/Apr/15 19:41

4.0

KeyValue

0

1

600

0%

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
OS X 10.10

I declared a MultiValueMap as this:
{code}
MultiValueMap<Integer, Path> duplicates = new MultiValueMap<Integer, Path>();
{code}

Elsewhere in code I doing (by accident) something in this direction
{code}
duplicates.put(number, new LinkedList<Path>());
{code}

Exceptions were being thrown when values returned from the list could not be assigned to variables of type Path.

{code:title=org.apache.commons.collections4.map.MultiValueMap.java}
public Object put(final K key, final Object value) {
...
{code}
I propose that Object in the above decleration is changed to T.

0%

600

4 years, 50 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i27nsv:

Commons Collections

COLLECTIONS-558

ListOrderedSet#remove(int) should return E instead of Object

Bug

Closed

Major

Fixed

Unassigned

Felix Rabe

25/Mar/15 14:46

27/Nov/15 21:11

25/Mar/15 16:03

4.0

4.1

Set

0

1

Since {{List#remove(int)}} returns {{E}} the implementation in {{ListOrderedSet}} should also return {{E}}.

Minimal example that fails to compile:
{code:java}
ListOrderedSet<String> los = new ListOrderedSet<String>();
los.add("foo");
String s = los.remove(0);
{code}

25/Mar/15 4:03 PM

4 years, 51 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i27c8f:

Commons Collections

COLLECTIONS-576

MultiKey subclassing has deserialization problem since COLLECTIONS-266: either declare protected readResolve() or MultiKey must be final

Bug

Closed

Major

Fixed

Unassigned

Stephan Roch

03/Sep/15 08:44

27/Nov/15 21:11

28/Sep/15 08:54

4.0

4.1

KeyValue

0

1

COLLECTIONS-266

MultiKey from collections 4 provides a transient hashCode and a *private* readResolve to resolve COLLECTIONS-266: Issue with MultiKey when serialized/deserialized via RMI.

Unfortunately the solution does not work in case of *subclassing*: readResolve in MultiKey should be declared *protected* readResolve() to be called during deserialization of the subclass. Otherwise MultiKey must be final to avoid such subclassing.

*Testcase*:
{code:java|title=MultiKeySerializationTest.java}
package de.ivu.test.common.collections4;

import static org.junit.Assert.assertEquals;

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

import org.apache.commons.collections4.keyvalue.MultiKey;
import org.junit.Test;

public class MultiKeySerializationTest {

@Test
@SuppressWarnings("unchecked")
public void testReadResolveEqualHashCode()
throws IOException, ClassNotFoundException {
class MultiKey2<A, B>
extends MultiKey {

private static final long serialVersionUID = 1928896152249821416L;

public MultiKey2(A key1, B key2) {
super(key1, key2);
}

public A getFirst() {
return (A) getKey(0);
}

public B getSecond() {
return (B) getKey(1);
}

// FIXME: MultiKey should either declare protected readResolve() or must be final.
}
MultiKey2<String, String> one = new MultiKey2<>("bla", "blub");
System.out.println(one.hashCode());
ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(byteOut);
out.writeObject(one);
out.close();
byte[] serialized = byteOut.toByteArray();
ByteArrayInputStream byteIn = new ByteArrayInputStream(serialized);
ObjectInputStream in = new ObjectInputStream(byteIn);
MultiKey2<String, String> two = (MultiKey2<String, String>) in.readObject();
System.out.println(two.hashCode());
assertEquals("hashCode must be equal - please check for protected readResolve in MultiKey*", one.hashCode(),
two.hashCode());
}
}
{code}

*Fix:*
{code:java|title=MultiKey.java}
@@ -274,7 +274,7 @@
* only stable for the same process).
* @return the instance with recalculated hash code
*/
- private Object readResolve() {
+ protected Object readResolve() {
calculateHashCode(keys);
return this;
}
{code}

28/Sep/15 8:54 AM

4 years, 25 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2jqh3:

Commons Collections

COLLECTIONS-506

Result of CollectionUtils are different between version 3.2.1 and version 4.0

Bug

Closed

Major

Fixed

Unassigned

Anthony Communier

22/Dec/13 19:13

27/Nov/15 21:11

31/Dec/13 16:25

4.0

4.1

0

1

CollectionUtils V3 uses equals to compute results but not CollectionUtils v4 (it seems to use ==)

The following exemple with subtract method :

List<ObjectTest> listA = new ArrayList<ObjectTest>();
List<ObjectTest> listB = new ArrayList<ObjectTest>();

listA.add(new ObjectTest("Test1"));
listA.add(new ObjectTest("Test2"));
listA.add(new ObjectTest("Test3"));

listB.add(new ObjectTest("Test1"));
listB.add(new ObjectTest("Test2"));

Collection<?> res1 = org.apache.commons.collections.CollectionUtils.subtract(listA, listB);
System.out.println("Res1 size = " +res1.size());
Collection<?> res2 = org.apache.commons.collections4.CollectionUtils.subtract(listA, listB);
System.out.println("Res2 size = " +res2.size());

Produces this :
Res1 size = 1
Res2 size = 3

The new behaviour is not useful. It would be better to have the V3 behaviour

22/Dec/13 8:04 PM

6 years, 11 weeks, 5 days ago

365027

No Perforce job exists for this issue.

1

365335

0|i1qx3b:

Commons Collections

COLLECTIONS-504

CompositeMap should support compositing of maps of derived types

Bug

Closed

Minor

Invalid

Unassigned

Peter Cooper Jr.

03/Dec/13 20:33

04/Dec/13 15:32

04/Dec/13 12:56

4.0

Map

0

1

I'm attempting to composite two maps, one of which is a {{Map<String, String>}} and the other of which is a {{Map<String, Object>}}. I would have expected that I could composite them into a {{CompositeMap<String, Object>}}, but the constructors of CompositeMap expect all of the maps being composited to have exactly the same type arguments.

That is, I think the constructors should take arguments of {{Map<? extends K, ? extends V>}} instead of what they currently have of {{Map<K, V>}}, much like most collection methods, since there shouldn't be a problem accepting type arguments that are subtypes of the composite map types.

Thanks!

03/Dec/13 10:07 PM

6 years, 15 weeks, 6 days ago

361767

No Perforce job exists for this issue.

0

362064

0|i1qczz:

Commons Collections

COLLECTIONS-526

PatriciaTrie

Bug

Closed

Critical

Duplicate

Unassigned

zigler zhang

08/May/14 04:38

08/May/14 06:04

4.0

Collection

0

1

COLLECTIONS-525

android

the result of trie tree prefixMap function is inconsistent. it would contain a key but the size is 0;
some unittest codes as below:

PatriciaTrie<String> aTree =
new PatriciaTrie<String> ();
aTree.put("点评", "测试");
aTree.put("书评", "测试");
assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass
assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass
assertFalse(aTree.prefixMap("点").isEmpty()); //fail
assertEquals(1, aTree.prefixMap("点").size()); //fail
assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail
assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail
assertEquals(1, aTree.prefixMap("点评").values().size()); //fail

5 years, 45 weeks, 5 days ago

391330

No Perforce job exists for this issue.

0

391550

0|i1vedz:

Commons Collections

COLLECTIONS-525

PatriciaTrie

Bug

Closed

Critical

Fixed

Unassigned

zigler zhang

08/May/14 04:38

27/Nov/15 21:11

01/Jan/15 21:11

4.0

4.1

Collection

0

1

COLLECTIONS-526

android

the result of trie tree prefixMap function is inconsistent. it would contain a key but the size is 0;
some unittest codes as below:

PatriciaTrie<String> aTree =
new PatriciaTrie<String> ();
aTree.put("点评", "测试");
aTree.put("书评", "测试");
assertTrue(aTree.prefixMap("点").containsKey("点评")); //pass
assertEquals("测试", aTree.prefixMap("点").get("点评")); //pass
assertFalse(aTree.prefixMap("点").isEmpty()); //fail
assertEquals(1, aTree.prefixMap("点").size()); //fail actural 0
assertEquals(1, aTree.prefixMap("点").keySet().size()); //fail actural 0
assertEquals(1, aTree.prefixMap("点").entrySet().size()); //fail actural 0
assertEquals(1, aTree.prefixMap("点评").values().size()); //fail actural 0

14/May/14 1:30 PM

5 years, 11 weeks, 5 days ago

391329

No Perforce job exists for this issue.

1

391549

0|i1vedr:

Commons Collections

COLLECTIONS-537

PredicateUtils (all|any)Predicate type misbehaviour Array vs. Collection

Bug

Closed

Major

Fixed

Unassigned

Frank Jakop

13/Nov/14 12:47

27/Nov/15 21:11

30/Dec/14 18:25

4.0

4.1

Functor

0

1

Migrating from collections-generic to collections4 we encountered a type problem with PredicateUtils. When you look at the method anyPredicate(), the signature with array is typed with "Predicate<? super T>" whereas the signature with Collection is typed "? extends Predicate<T>", so the both methods are not equivalent.
We think both methods should have the same types, so it would not break compatibility with a lot of legacy code.

26/Dec/14 1:29 PM

5 years, 12 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i22bvr:

Commons Collections

COLLECTIONS-534

Performance bug in CollectionBag::retainAll

Bug

Closed

Major

Fixed

Unassigned

Oswaldo Olivo

15/Oct/14 21:01

27/Nov/15 21:11

19/Oct/14 12:44

4.0

4.1

Bag, Collection

0

1

Ubuntu 12.04

Hi,
There seems to be a performance bug in the method retainAll in the CollectionBag class.
The problem is that the code is checking containment over the parameter collection, which could be expensive for some types of collections like ArrayLists.
One solution could be to convert the Collection into a HashSet and check containment in the HashSet.
If this is done, then running retainAll on a 1,000,000 collection would take less than 2 seconds instead of 27 mins, according to my experiments.

____________________________________________
Here's a function to expose the bug:

public static void collectionBagRetainAllTest() {

ArrayList<Integer> coll=new ArrayList<Integer>();
for(int i=0;i<=1000000;++i)
coll.add(new Integer(i));

TreeBag<Integer> treeBag=new TreeBag<Integer>(coll);

CollectionBag<Integer> bag = new CollectionBag<Integer>(treeBag);

bag.retainAll(coll);
}
_____________________________________

Here's a proposed patch:

public boolean retainAll(final Collection<?> coll) {
if (coll != null) {
boolean modified = false;
final Iterator<E> e = iterator();
HashSet<Object> set=new HashSet<Object>(coll);
while (e.hasNext()) {
if (!set.contains(e.next())) {
e.remove();
modified = true;
}
}
return modified;
} else {
// let the decorated bag handle the case of null argument
return decorated().retainAll(null);
}
}
_____________________________________

perfomance

15/Oct/14 9:12 PM

5 years, 22 weeks, 2 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i217vb:

Commons Collections

COLLECTIONS-391

Inconsistent Javadoc comment and code for toProperties(final Map<K, V>) in org.apache.commons.collections.MapUtils

Bug

Closed

Major

Fixed

Unassigned

SHIN HWEI TAN

08/Jan/12 08:38

18/Mar/20 03:00

09/Nov/14 14:31

09/Apr/12 18:03

4.0, 4.x

4.0-alpha1, 4.0

Collection

0

120

0%

Platform Indepedent

The Javadoc comment below states that the parameter map "..., may not be null":
/**
..
* @param map the map to convert to a Properties object, may not be null
* @return the properties object
*/
public static <K, V> Properties toProperties(final Map<K, V> map) {
Properties answer = new Properties();
if (map != null) {
...
}
return answer;
}
However, the method return normally without throwing any exception when called with null.

Suggested Fixes:
1. Change "@param map the map to convert to a Properties object, may not be null" to "@param map the map to convert to a Properties object, may be null"
or
2. Remove "may not be null" from @param.

0%

120

javadoc, null

09/Apr/12 6:03 PM

7 years, 50 weeks, 1 day ago

223174

No Perforce job exists for this issue.

0

164364

0|i0shtj:

Commons Collections

COLLECTIONS-390

Inconsistent Javadoc comment and code for mapTransformer(Map<? super I, ? extends O>) in org.apache.commons.collections.TransformerUtils

Bug

Closed

Major

Duplicate

Unassigned

SHIN HWEI TAN

08/Jan/12 08:31

24/Jun/13 19:34

08/Jan/12 08:32

4.0

Buffer

0

120

0%

Platform Independent

The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null":
/**
....
* @param map the map to use to transform the objects
* @return the transformer
* @throws IllegalArgumentException if the map is null
*/
public static <I, O> Transformer<I, O> mapTransformer(Map<? super I, ? extends O> map) {
return MapTransformer.mapTransformer(map);
}
However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null.

Suggested Fixes:
1. Change "@throws IllegalArgumentException if the map is null" and "@return" to "@return NULL_INSTANCE if the map is null".
or
2. Remove the entire "throws IllegalArgumentException if the map is null".

0%

120

8 years, 11 weeks, 2 days ago

223173

No Perforce job exists for this issue.

0

164365

0|i0shtr:

Commons Collections

COLLECTIONS-389

Inconsistent Javadoc comment and code for mapTransformer(Map<? super I, ? extends O>) in org.apache.commons.collections.TransformerUtils

Bug

Closed

Major

Fixed

Unassigned

SHIN HWEI TAN

08/Jan/12 08:31

09/Nov/14 14:31

09/Apr/12 17:21

4.0, 4.x

4.0-alpha1, 4.0

Collection

0

120

0%

Platform Independent

The Javadoc comment below states that the method "throws IllegalArgumentException if the map is null":
/**
....
* @param map the map to use to transform the objects
* @return the transformer
* @throws IllegalArgumentException if the map is null
*/
public static <I, O> Transformer<I, O> mapTransformer(Map<? super I, ? extends O> map) {
return MapTransformer.mapTransformer(map);
}
However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null.

Suggested Fixes:
1. Change "@throws IllegalArgumentException if the map is null" and "@return" to "@return NULL_INSTANCE if the map is null".
or
2. Remove the entire "throws IllegalArgumentException if the map is null".

0%

120

javadoc, null

09/Apr/12 5:21 PM

7 years, 50 weeks, 1 day ago

223172

No Perforce job exists for this issue.

0

164366

0|i0shtz:

Commons Collections

COLLECTIONS-388

Inconsistent Javadoc comment and code for prototypeFactory(T) in org.apache.commons.collections.FactoryUtils

Bug

Closed

Major

Fixed

Unassigned

SHIN HWEI TAN

08/Jan/12 08:29

09/Nov/14 14:31

09/Apr/12 17:16

4.0, 4.x

4.0-alpha1, 4.0

Collection

0

120

0%

Platform independent

The Javadoc comment below states that the method "throws IllegalArgumentException if the prototype is null":
/**
..
* @param prototype the object to clone each time in the factory
* @return the <code>prototype</code> factory
* @throws IllegalArgumentException if the prototype is null
* @throws IllegalArgumentException if the prototype cannot be cloned
*/
public static <T> Factory<T> prototypeFactory(T prototype) {
return PrototypeFactory.<T>prototypeFactory(prototype);
}

However, the method returns a NULL_INSTANCE object instead of throwing IllegalArgumentException when called with null.

Suggested Fixes:
1. Change "@throws IllegalArgumentException if the prototype is null" and "@return" to "@return NULL_INSTANCE if the prototype is null".
or
2. Remove the entire "throws IllegalArgumentException if the prototype is null".

0%

120

javadoc, null

09/Apr/12 5:14 PM

7 years, 50 weeks, 1 day ago

223171

No Perforce job exists for this issue.

0

164367

0|i0shu7:

Commons Collections

COLLECTIONS-604

More uniform safe-null methods in CollectionUtils

Bug

Open

Minor

Unresolved

Bruno P. Kinoshita

26/May/17 12:41

12/Nov/19 08:27

4.1

Collection

1

4

COLLECTIONS-600

Currently, there are 65 public methods in `CollectionUtils`. And 53 without the deprecated ones. Out of these, 24 handle `null` arguments. The remaining methods throw a `NullPointerException` (NPE) at some part of its code.

The methods that handle nulls, throw NPE, or return empty columns, boolean values, or just doesn't do anything.

As a user of the API, I would expect a more uniform behaviour across the methods of `CollectionUtils`. COLLECTIONS-600 address one of these methods.

`removeAll` (2x) and `retainAll` (2x) both state that a NPE will be thrown if either parameter is `null`. However, they never check if the values are null, and instead allow the code to run until a NPE is thrown.

And the following code shows that `isEmpty` and `isFull` behave differently too.

{code:java}
Collection<String> c = null;
System.out.println(CollectionUtils.isEmpty(c)); // return true
System.out.println(CollectionUtils.isFull(c)); // throws a NPE
{code}

If I don't have to worry about `null`s with `#isEmpty`, I would expect the same from its related-method `#isFull`.

What would be a good approach for it? Define a behaviour to all methods? Or leave as is, but add more documentation?

There are a few methods that can easily be updated to check for `null` values. Others would require a bit more thinking. An example if the method in question for COLLECTIONS-600. It checks equality of collections, and when both collections are `null`, it says that they are equals. Google Guava [Iterables#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterables.java#L232] and [Iterators#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterators.java#L274] do not check for null values, for what it is worth.

28/May/17 2:00 PM

18 weeks ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

0|i3fipr:

Commons Collections

COLLECTIONS-709

MultiSet.Entry::getCount() isn't 0 after removing the last element

Bug

Closed

Minor

Fixed

Unassigned

Robert Wertman

19/Jan/19 23:30

18/Mar/20 02:59

20/Jan/19 17:41

20/Jan/19 15:06

4.1, 4.2

4.3

0

1

0

1800

Removing the final element(s) in a MultiSet doesn't set the count on a MultiSet.Entry to zero.
{code:java}
protected int getCountAfterRemoval(MultiSet<String> multiset) {
MultiSet.Entry<String> entry = multiset.entrySet().iterator().next();
entry.getCount(); // = 2
multiset.remove(entry.getElement());
entry.getCount(); // = 1
multiset.remove(entry.getElement());
return entry.getCount(); // Still = 1, should be 0
}
{code}

100%

1800

0

20/Jan/19 3:06 PM

1 year, 8 weeks, 2 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|yi03i8:

Commons Collections

COLLECTIONS-721

functors.InvokerTransformer backward incompatibility bug

Bug

Closed

Major

Not A Bug

Unassigned

xia0c

16/Jun/19 21:48

18/Mar/20 02:59

24/Jul/19 18:57

24/Jul/19 18:56

4.1, 4.2, 4.3

0

3

COLLECTIONS-580

The following code snippets throw a NotSerializableException. It works well before commons-collections4 4.0 and commons-collection3. When I update it to 4.1 or newer versions, it failed.

{code:java}
@Test
public void Demo() throws IOException{
InvokerTransformer transformer = new InvokerTransformer("toString", new Class[]{}, new Object[]{});
Queue priorityQueue = new PriorityQueue(2, new TransformingComparator(transformer));
priorityQueue.add(1);

ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bout);
out.writeObject(priorityQueue);

}
{code}

performance

24/Jul/19 3:20 AM

33 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Important

0|z03suo:

Commons Collections

COLLECTIONS-722

IteratorUtils.chainedIterator() Performance Degrades

Bug

Open

Major

Unresolved

Unassigned

E P

27/Jun/19 14:10

18/Mar/20 02:08

01/Nov/19 22:17

4.1

0

2

IteratorUtils.chainedIterator() performance degrades when chaining iterators with chained iterators. The slowdown appears to be exponential, based upon the number of chains created. The attached test shows the issue.

As a reference, the same test below works as expected using Google's Guava Iterator.concat() functionality. It is possible I am misusing the API, but the javadoc did not indicate as much.

01/Nov/19 9:07 AM

19 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

0|z045w8:

Commons Collections

COLLECTIONS-673

ListUtils.partition potential integer overflow

Bug

Resolved

Major

Fixed

Unassigned

John Mark

02/Feb/18 17:18

12/Jun/18 21:45

4.1

4.2

List

0

3

When calling {{ListUtils.partition()}} with a large size and large list, it is possible that an integer overflow will occur in the {{size()}} method that causes incorrect behavior. This will occur when using a size that, when added to list.size() will be larger than {{Integer.MAX_VALUE}}

Current version of Guava's {{Lists.partition()}} handle this correctly, so perhaps the code for {{ListUtils.partition()}} needs to be updated based on the latest Guava code.

A simple illustration of this:
{code}
List<String> aList = Arrays.asList("1", "2", "3", "4", "5");
List<List<String>> partitioned = ListUtils.partition(aList, Integer.MAX_VALUE);
System.out.println("Number of partitions: " + partitioned.size());
for(List<String> l : partitioned) {
System.out.println(l);
}
{code}

The above code works correctly when using Guava's {{Lists.partition()}} instead.

03/Feb/18 1:03 AM

1 year, 40 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3ppz3:

Commons Collections

COLLECTIONS-661

Intermittent test failures in Windows for HashSetValuedHashMap

Bug

Resolved

Major

Fixed

Bruno P. Kinoshita

03/Oct/17 09:54

12/Oct/17 06:31

4.1

4.2

Map

0

3

The collection HashSetValuedHashMap was added in 4.1. On Windows, test failures are not so common on JVM 8. But on Linux they are harder to happen (but still do [1], [2]).

When using Windows and JVM 8, running tests on Eclipse, or Maven fail. But debugging on Windows with Eclipse sometimes work. Indicating it may be due to a concurrency issue, where debugging adds some extra time hiding the real issue.

I have a few ideas of where/why it could be happening, but am without a Windows box for a few days as I'm travelling. I'm reading the codebase in the meantime, but if anybody feels like working on it, feel free to chime in and suggest a fix/patch.

[1] https://travis-ci.org/apache/commons-collections/jobs/282169803
[2] http://markmail.org/thread/exwm7ggjtxzbtlkd

03/Oct/17 6:37 PM

2 years, 22 weeks, 5 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3kthr:

Commons Collections

COLLECTIONS-660

Uncomment test in AbstractMapTest regarding LRUMap equals

Bug

Resolved

Minor

Fixed

Bruno P. Kinoshita

03/Oct/17 09:41

04/Oct/17 04:44

04/Oct/17 04:39

4.1

4.2

Map

0

1

AbstractMapTest has a [commented out|https://github.com/apache/commons-collections/blob/c8bdf60d1d0be609094e14054be0b9af0fb05521/src/test/java/org/apache/commons/collections4/map/AbstractMapTest.java#L1959] line, with a comment as follows:

{quote}his fails for LRUMap because confirmed.equals() somehow modifies map, causing concurrent modification exceptions.{quote}

While working on another test failing on Windows, I believe I've found the why for that comment, and how to fix it. Just need to finish debugging another part, and find a good Internet connection to push the fix.

2 years, 23 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Patch

0|i3ktfz:

Commons Collections

COLLECTIONS-657

"union" method is resulting in data loss

Bug

Closed

Critical

Invalid

Unassigned

Igor Savin

19/Sep/17 18:12

19/Sep/17 18:38

4.1

0

1

Create 2 instances of StringReader from strings (1 and 2), put them into a list A.
Create empty list B.
Call CollectionUtils.union(A, B);

Expected result: [1, 2]
Actual result: [1, 1].

2 years, 26 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3k8wv:

Commons Collections

COLLECTIONS-656

Fix site build on Java 8

Bug

Resolved

Minor

Fixed

Bruno P. Kinoshita

12/Sep/17 10:42

13/Sep/17 07:52

4.1

4.2

0

2

Building the current master branch from git fails with

{noformat}
[INFO] Generating "FindBugs" report --- findbugs-maven-plugin:2.5.5:findbugs
[INFO] Locale is en
[INFO] Fork Value is true
[java] The following errors occurred during analysis:
[java] Error scanning java/util/Map$Entry for referenced classes
[java] java.lang.ArrayIndexOutOfBoundsException: 5735
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Error scanning java/util/Comparator for referenced classes
[java] java.lang.ArrayIndexOutOfBoundsException: 1320
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for java/util/AbstractMap$SimpleEntry
[java] java.lang.ArrayIndexOutOfBoundsException: 5735
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
[java] Unable to get XClass for org/apache/commons/collections4/map/StaticBucketMap$Node
[java] java.lang.ArrayIndexOutOfBoundsException: 5735
[java] At org.objectweb.asm.ClassReader.readClass(Unknown Source)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
[java] At org.objectweb.asm.ClassReader.accept(Unknown Source)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76)
[java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
[java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268)
[java] At edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:891)
[java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:222)
[java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393)
[java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317)
...
{noformat}

Tested locally, and updating the commons-parent version to 42, and specifying the findbugs version from the parent property seems to fix the issue. As it could affect other parts of the build/release artefacts, I'll send a pull request to allow others to review before the parent is updated.

documentation, site

12/Sep/17 10:45 PM

2 years, 27 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Patch

0|i3jyhr:

Commons Collections

COLLECTIONS-717

ObjectInputFilter REJECTED: class org.apache.commons.collections.functors.InstantiateFactory

Bug

Open

Major

Unresolved

Unassigned

kirubakaran

20/May/19 13:31

05/Jul/19 15:24

4.1

Functor

0

2

WebLogic 12.2.1.3 server

we have an object rejection issue with latest version of common collection for the class InstantiateFactory

we have set system property to enable unsafe serialization= true but still we have object rejection for org.apache.commons.collections.functors.InstantiateFactory.

can you please help us to resolve the issue.

Error log:

DOMAIN] > <BEA-000000> <ObjectInputFilter REJECTED: class org.apache.commons.collections.functors.InstantiateFactory, array length: -1, nRefs: 3, depth: 2, bytes: 229, ex: n/a>

####<May 8, 2019 1:08:43,859 PM EDT> <Error> <RJVM> <nygindapnp613.us.db.com> <MS1> <ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <a8f22bc1-d077-4f1b-be08-7677cfc592c6-00000005> <1557335323859> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000503> <Incoming message header or abbreviation processing failed.

java.io.InvalidClassException: filter status: REJECTED

java.io.InvalidClassException: filter status: REJECTED

 at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1255)

 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1878)

 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)

 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1560)

 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)

 at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:106)

 at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2118)

 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2067)

 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)

 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)

 at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:73)

 at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:45)

 at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:324)

 at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:219)

 at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:556)

 at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:658)

 at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:397)

 at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:981)

 at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:917)

 at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:171)

 at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)

 at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)

 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)

 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

05/Jul/19 3:24 PM

36 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z02uxs:

Commons Collections

COLLECTIONS-554

NullPointerException in CollectionUtils.partition

Bug

Closed

Minor

Invalid

Unassigned

M Kim

16/Feb/15 16:33

27/Nov/15 21:47

07/Apr/15 12:41

4.1

Collection

0

1

NullPointerException (NPE) is not suitably handled in CollectionUtils.partition. With a nullFactory, partitions.get(numberOfPredicates) can be null at line partitions.get(numberOfPredicates).add(element);.

Stack trace:
{code}
test(Test)java.lang.NullPointerException
at org.apache.commons.collections4.CollectionUtils.partition(CollectionUtils.java:1187)
at Test.test(Test.java:18)
{code}

Test case:
{code}
public void test() {
Collection input = CollectionUtils.permutations((java.util.Collection)new CircularFifoQueue(10));
Factory factory = FactoryUtils.nullFactory();
NullIsFalsePredicate p = new NullIsFalsePredicate(NullPredicate.nullPredicate());
Predicate[] predicates = p.getPredicates();
CollectionUtils.<java.lang.Object,java.util.Collection>partition((java.lang.Iterable)input, factory, predicates);
}

{code}

16/Feb/15 6:56 PM

4 years, 50 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i25opb:

Commons Collections

COLLECTIONS-555

Undefined NullPointerException in TreeBag.java

Bug

Closed

Minor

Fixed

Unassigned

M Kim

16/Feb/15 17:03

27/Nov/15 21:11

17/Feb/15 22:03

4.1

Bag

0

1

In add(final E object) method of TreeBag.java, the parameter object is not null-checked in throw IlligalArgumentException statement. Thus, it crashes with an inappropriate type of exceptions when the parameter, object is null. object can be null from the argument, transform(object) in TransformedCollection.add(final E object).
I think object ==null should be added in the predicate of the throw IlligalArgumentException statement like below.

{code}
public boolean add(final E object) {
if((object==null) || (comparator() == null && !(object instanceof Comparable))) {
throw new IllegalArgumentException("Objects of type " + object.getClass() + " cannot be added to " +
"a naturally ordered TreeBag as it does not implement Comparable");
}
return super.add(object);
}
{code}

17/Feb/15 10:03 PM

5 years, 5 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i25oqv:

Commons Collections

COLLECTIONS-544

Undocumented performance issue in the retainAll method in CollectionUtils

Bug

Closed

Trivial

Fixed

Unassigned

Oswaldo Olivo

12/Jan/15 05:55

27/Nov/15 21:11

12/Jan/15 14:06

4.1

Collection

0

2

Ubuntu 14.04

The method {{retainAll}} in {{CollectionUtils}} is inefficient when the parameter collection has a slow containment method.

The following is the current implementation with its documentation:

{noformat}
/**
* Returns a collection containing all the elements in <code>collection</code>
* that are also in <code>retain</code>. The cardinality of an element <code>e</code>
* in the returned collection is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>c.retainAll(retain);</code>.
*
* @param <C> the type of object the {@link Collection} contains
* @param collection the collection whose contents are the target of the #retailAll operation
* @param retain the collection containing the elements to be retained in the returned collection
* @return a <code>Collection</code> containing all the elements of <code>collection</code>
* that occur at least once in <code>retain</code>.
* @throws NullPointerException if either parameter is null
* @since 3.2
*/
public static <C> Collection<C> retainAll(final Collection<C> collection, final Collection<?> retain) {
return ListUtils.retainAll(collection, retain);
}
{noformat}

We can notice the inefficiency by looking at the {{retainAll}} method in {{ListUtils}}.

The {{retainAll}} method from {{ListUtils}} is implemented and documented as follows:

{noformat}
/**
* Returns a List containing all the elements in <code>collection</code>
* that are also in <code>retain</code>. The cardinality of an element <code>e</code>
* in the returned list is the same as the cardinality of <code>e</code>
* in <code>collection</code> unless <code>retain</code> does not contain <code>e</code>, in which
* case the cardinality is zero. This method is useful if you do not wish to modify
* the collection <code>c</code> and thus cannot call <code>collection.retainAll(retain);</code>.
* 
* This implementation iterates over <code>collection</code>, checking each element in
* turn to see if it's contained in <code>retain</code>. If it's contained, it's added
* to the returned list. As a consequence, it is advised to use a collection type for
* <code>retain</code> that provides a fast (e.g. O(1)) implementation of
* {@link Collection#contains(Object)}.
*
* @param <E> the element type
* @param collection the collection whose contents are the target of the #retailAll operation
* @param retain the collection containing the elements to be retained in the returned collection
* @return a <code>List</code> containing all the elements of <code>c</code>
* that occur at least once in <code>retain</code>.
* @throws NullPointerException if either parameter is null
* @since 3.2
*/
public static <E> List<E> retainAll(final Collection<E> collection, final Collection<?> retain) {
final List<E> list = new ArrayList<E>(Math.min(collection.size(), retain.size()));

for (final E obj : collection) {
if (retain.contains(obj)) {
list.add(obj);
}
}
return list;
}
{noformat}

In the case of {{ListUtils#retainAll}}, the inefficiency is properly documented.

Perhaps the disclaimer about potential inefficiencies depending on the type
of the parameter collection in ListUtils:retainAll should also be included in {{CollectionUtils#retainAll}}.

Collections, documentaion, performance

12/Jan/15 12:02 PM

5 years, 10 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i248x3:

Commons Collections

COLLECTIONS-595

ListOrderedSet remove()

Bug

Resolved

Major

Not A Bug

Unassigned

Maleven

25/Sep/16 21:08

24/May/17 09:52

4.1

Set

0

3

Windows 10, Eclipse Neon Release (4.6.0)

Hello Apache,

I have a class which overrides equals() and hashCode().
I create a ListOrderedSet<MyClass> mySet= new ListOrderedSet<MyClass>(), and add objects to it:
mySet.add(obj1);
etc.

Each object is initialized in the constructor with two properties first. The other properties are set afterwards, when
they are already contained in the ListOrderedSet. After I change/add some properties, then if I do mySet.contains(obj1), false is returned.
I read about that when a hashmap is created with the objects inside and then changing the objects inside it does not change
the hasmap's internal hashcode for the objects or something like that.

These properties are found in the equals and hashcode. (When not there is no issue.).

The following happens. If I still want to remove an object which was changed afterwards, in the method: public E remove(final int index),
inside public E remove(final int index) false is returned. But the object is still removed and in the debugger the following can be seen:

DEBUG Info:

this.collections.map.size == 5 (internal HashMap)
this.collections.setOrder.size == 4. (internal ArrayList)

Afterwards if I print the list with the overrided toString() method IndexOutOfBoundsException is thrown when getting the size of mySet
via mySet.size(), but not when I use an iterator to count the objects in the set.

{code:java}
public int getSize() {

OrderedIterator it = mySet.iterator();
int i = 0;
while(it.hasNext()){

it.next();
i++;

}
//if i return i then the items are 4, when returning memorySet.size(), the items are 5.
// return i;
return mySet.size();

}

@Override
public String toString() {

String toReturn = "\n";

for (int i = 0; i < getSize(); i++) {

toReturn = toReturn + mySet.get(i) + "\n";

}
return toReturn;

}
{code}

So my question is: is this a bug or is it because of my changing/updating the objects in the list, and why if it returns false when removing it got deleted anyway?
Should it not got deleted to start with?

Thank you for your effort.

P.S. I am a self taught programmer. It's my first time sending a bug issue, maybe it's a bit long or I did not send with it other information I should have.

28/Oct/16 4:57 PM

2 years, 42 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i34267:

Commons Collections

COLLECTIONS-584

Deserializing an AbstractHashedMap expands the hash table exponentially

Bug

Closed

Major

Invalid

Unassigned

Diogo Sousa

14/Dec/15 18:08

14/Dec/15 22:49

14/Dec/15 18:51

4.1

0

1

When deserializing an {{AbstractHashedMap}} the size of the hashtable will be doubled at each element inserted because {{threshold}} = 0, so this

{code}
protected void checkCapacity() {
if(this.size >= this.threshold) {
int newCapacity = this.data.length * 2;
if(newCapacity <= 1073741824) {
this.ensureCapacity(newCapacity);
}
}
}
{code}

will always expand the hashtable.

14/Dec/15 6:30 PM

4 years, 14 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2pvan:

Commons Collections

COLLECTIONS-586

PatriciaTrie prefixMap clear throws NullPointerException

Bug

Closed

Major

Fixed

Unassigned

Shailender Bathula

12/Apr/16 21:59

18/Jul/17 18:56

04/Aug/16 17:33

4.1

0

4

Clearing all entries of a prefixMap returned by PatriciaTrie using the {{clear}} method throws a NullPointerException. The workaround of removing each entry using the {{remove}} method seems to work.

Here are the test cases for the bug and the workaround:

{code:java}
public class PatriciaTrieTest {

private Trie<String, Integer> trie;

@Before
public void setUp() {
trie = new PatriciaTrie<Integer>();
trie.put("Anna", 1);
trie.put("Anael", 2);
trie.put("Analu", 3);
trie.put("Andreas", 4);
trie.put("Andrea", 5);
trie.put("Andres", 6);
trie.put("Anatole", 7);
}

@Test
public void testPrefixMapClear() {
SortedMap<String, Integer> prefixMap = trie.prefixMap("And");
assertEquals(new HashSet<>(Arrays.asList("Andrea", "Andreas", "Andres")), prefixMap.keySet());
assertEquals(Arrays.asList(5, 4, 6), new ArrayList<>(prefixMap.values()));

prefixMap.clear();
assertTrue(prefixMap.keySet().isEmpty());
assertTrue(prefixMap.values().isEmpty());
assertEquals(new HashSet<>(Arrays.asList("Anael", "Analu", "Anatole", "Anna")), trie.keySet());
assertEquals(Arrays.asList(2, 3, 7, 1), new ArrayList<>(trie.values()));
}

@Test
public void testPrefixMapClearUsingRemove() {
SortedMap<String, Integer> prefixMap = trie.prefixMap("And");
assertEquals(new HashSet<>(Arrays.asList("Andrea", "Andreas", "Andres")), prefixMap.keySet());
assertEquals(Arrays.asList(5, 4, 6), new ArrayList<>(prefixMap.values()));

Set<String> keys = new HashSet<String>(prefixMap.keySet());
for (final String key : keys) {
prefixMap.remove(key);
}
assertTrue(prefixMap.keySet().isEmpty());
assertTrue(prefixMap.values().isEmpty());
assertEquals(new HashSet<>(Arrays.asList("Anael", "Analu", "Anatole", "Anna")), trie.keySet());
assertEquals(Arrays.asList(2, 3, 7, 1), new ArrayList<>(trie.values()));
}

}
{code}

The stacktrace of the NullPointerException thrown by the {{testPrefixMapClear}} test case is:
{noformat}
java.lang.NullPointerException
at org.apache.commons.collections4.trie.AbstractPatriciaTrie$PrefixRangeEntrySet$EntryIterator.remove(AbstractPatriciaTrie.java:2370)
at java.util.AbstractCollection.clear(AbstractCollection.java:432)
at java.util.AbstractMap.clear(AbstractMap.java:288)
at PatriciaTrieTest.testPrefixMapClear(PatriciaTrieTest.java:39)
{noformat}

04/Aug/16 4:00 PM

2 years, 35 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2w0vz:

Commons Collections

COLLECTIONS-710

NullPointerExceptions in CompositeCollection, CompositeSet, and CompositeMap

Bug

Resolved

Major

Fixed

Unassigned

Yu Shi

29/Jan/19 22:00

09/Feb/19 23:01

4.2

4.4

Collection, Map, Set

0

1

3600

0%

Windows 10

Eclipse IDE for Java Developers Version: 2018-09 (4.9.0)

If we first add a null element into CompositeCollection by CompositeCollection.addComposited(nullElement), projects will crash and throw java.lang.NullPointerException when we call CompositeCollection.size().

For example, we have following code:

ArrayList<String> nullList = null;
CompositeCollection<String> cc = new CompositeCollection<String>(list);
cc.addComposited(nullList);
System.out.println(cc.size());

We will get:

{{Exception in thread "main" java.lang.NullPointerException}}
at org.apache.commons.collections4.collection.CompositeCollection.size(CompositeCollection.java:103)

Because in CompositeCollection.size(), it iterate all items in the Collection, call item.size() and sum up their size. If the item point to null, the program will crash.

This bug also exists in other methods of CompositeCollection. Moreover, CompositeSet and CompositeMap have the same bug.

0%

3600

nullpointerexception

09/Feb/19 11:01 PM

1 year, 5 weeks, 3 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|yi0gfk:

Commons Collections

COLLECTIONS-695

PatriciaTrie.subMap() does not return the expected outcome

Bug

Resolved

Major

Invalid

Unassigned

Konrad Windszus

13/Sep/18 17:29

09/Oct/18 10:05

4.2

0

1

I use a {{PatriciaTrie}} to basically retrieve the entry whose key is the longest prefix of a requested key.

Now I do have a simple trie with only two entries:
# {{"/":<somevalue>}}
# {{"/libs/cq/flow/widgets":<someothervalue>"}}

If I call {{subMap("/", "/libs/cq/gui/components/authoring/dialog/"}} I would expect to only get back a map containing only entry 1. Instead I get back both entries. This happens primarily with those two specific keys.

According to the javadoc of {{PatriciaTrie}}
{quote}
The Trie can return operations in lexicographical order using the 'prefixMap', 'submap', or 'iterator' methods.
{quote}
(https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/trie/PatriciaTrie.html)
therefore I assumed that according to the lexicographical order only the "/" entry should be contained in here.

Is this a bug or am I misinterpreting the Javadoc?

1 year, 23 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3y2gn:

Commons Collections

COLLECTIONS-689

Link to Javadoc API broken

Bug

Closed

Minor

Fixed

Unassigned

Richard Walker

17/Jul/18 06:51

18/Jul/18 23:53

17/Jul/18 16:08

4.2

4.3

Collection

0

1

On the front page [https://commons.apache.org/proper/commons-collections/] in the Documentation section, the link to the Javadoc API for "The current release 4.2" is broken.

17/Jul/18 4:08 PM

1 year, 34 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3vyo7:

Commons Collections

COLLECTIONS-593

Compilation errors (generics) with JDK9

Bug

Closed

Major

Not A Problem

Unassigned

Vincent Privat

03/Jul/16 18:55

28/Mar/17 22:54

4.x

0

3

Java 9b125

Current codebase does not compile with JDK9 (build 125): 28 errors below.

I am not sure if this is a bug of JDK9 of a stricter compilation rule with generics.

[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/BagUtils.java:98: error: incompatible types: Bag<CAP#1> cannot be converted to Bag<E>
[javac] return UnmodifiableBag.unmodifiableBag(bag);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableBag(Bag<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:795: error: incompatible types: Collection<CAP#1> cannot be converted to Collection<C>
[javac] final Collection<C> resultCollection = collect(collection, transformer);
[javac] ^
[javac] where C is a type-variable:
[javac] C extends Object declared in method <C>transform(Collection<C>,Transformer<? super C,? extends C>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends C from capture of ? extends C
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/CollectionUtils.java:1835: error: incompatible types: Collection<CAP#1> cannot be converted to Collection<C>
[javac] return UnmodifiableCollection.unmodifiableCollection(collection);
[javac] ^
[javac] where C is a type-variable:
[javac] C extends Object declared in method <C>unmodifiableCollection(Collection<? extends C>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends C from capture of ? extends C
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/FluentIterable.java:311: error: incompatible types: FluentIterable<CAP#1> cannot be converted to FluentIterable<O>
[javac] return of(IterableUtils.transformedIterable(iterable, transformer));
[javac] ^
[javac] where O,E are type-variables:
[javac] O extends Object declared in method <O>transform(Transformer<? super E,? extends O>)
[javac] E extends Object declared in class FluentIterable
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O from capture of ? extends O
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:429: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<O>
[javac] return IteratorUtils.transformedIterator(iterable.iterator(), transformer);
[javac] ^
[javac] where O,I are type-variables:
[javac] O extends Object declared in method <I,O>transformedIterable(Iterable,Transformer<? super I,? extends O>)
[javac] I extends Object declared in method <I,O>transformedIterable(Iterable,Transformer<? super I,? extends O>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O from capture of ? extends O
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:833: error: no suitable method found for partition(Iterable<CAP#1>,Factory<List<O#1>>,Predicate<? super O#1>[])
[javac] return partition(iterable, factory, predicates);
[javac] ^
[javac] method IterableUtils.<O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>) is not applicable
[javac] (cannot infer type-variable(s) O#1
[javac] (actual and formal argument lists differ in length))
[javac] method IterableUtils.<O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>...) is not applicable
[javac] (cannot infer type-variable(s) O#2
[javac] (varargs mismatch; Factory<List<O#1>> cannot be converted to Predicate<? super O#2>))
[javac] method IterableUtils.<O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) is not applicable
[javac] (cannot infer type-variable(s) O#3,R
[javac] (varargs mismatch; Predicate<? super O#1>[] cannot be converted to Predicate<? super O#3>))
[javac] where O#1,O#2,O#3,R are type-variables:
[javac] O#1 extends Object declared in method <O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>)
[javac] O#2 extends Object declared in method <O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>...)
[javac] O#3 extends Object declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] R extends Collection<O#3> declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#1 from capture of ? extends O#1
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IterableUtils.java:873: error: no suitable method found for partition(Iterable<CAP#1>,Factory<List<O#1>>,Predicate<? super O#1>[])
[javac] return partition(iterable, factory, predicates);
[javac] ^
[javac] method IterableUtils.<O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>) is not applicable
[javac] (cannot infer type-variable(s) O#2
[javac] (actual and formal argument lists differ in length))
[javac] method IterableUtils.<O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>...) is not applicable
[javac] (cannot infer type-variable(s) O#1
[javac] (varargs mismatch; Factory<List<O#1>> cannot be converted to Predicate<? super O#1>))
[javac] method IterableUtils.<O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...) is not applicable
[javac] (cannot infer type-variable(s) O#3,R
[javac] (varargs mismatch; Predicate<? super O#1>[] cannot be converted to Predicate<? super O#3>))
[javac] where O#1,O#2,O#3,R are type-variables:
[javac] O#1 extends Object declared in method <O#1>partition(Iterable<? extends O#1>,Predicate<? super O#1>...)
[javac] O#2 extends Object declared in method <O#2>partition(Iterable<? extends O#2>,Predicate<? super O#2>)
[javac] O#3 extends Object declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] R extends Collection<O#3> declared in method <O#3,R>partition(Iterable<? extends O#3>,Factory<R>,Predicate<? super O#3>...)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#1 from capture of ? extends O#1
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:438: error: incompatible types: BoundedIterator<CAP#1> cannot be converted to BoundedIterator<E>
[javac] return boundedIterator(iterator, 0, max);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>boundedIterator(Iterator<? extends E>,long)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:862: error: incompatible types: PeekingIterator<CAP#1> cannot be converted to Iterator<E>
[javac] return PeekingIterator.peekingIterator(iterator);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>peekingIterator(Iterator<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:878: error: incompatible types: PushbackIterator<CAP#1> cannot be converted to Iterator<E>
[javac] return PushbackIterator.pushbackIterator(iterator);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>pushbackIterator(Iterator<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:1086: error: incompatible types: List<CAP#1> cannot be converted to List<E>
[javac] final List<E> list = toList(iterator, 100);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>toArray(Iterator<? extends E>,Class<E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/IteratorUtils.java:1104: error: incompatible types: List<CAP#1> cannot be converted to List<E>
[javac] return toList(iterator, 10);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>toList(Iterator<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/ListUtils.java:394: error: incompatible types: List<CAP#1> cannot be converted to List<E>
[javac] return UnmodifiableList.unmodifiableList(list);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableList(List<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MapUtils.java:1272: error: incompatible types: Map<CAP#1,CAP#2> cannot be converted to Map<K,V>
[javac] return UnmodifiableMap.unmodifiableMap(map);
[javac] ^
[javac] where K,V are type-variables:
[javac] K extends Object declared in method <K,V>unmodifiableMap(Map<? extends K,? extends V>)
[javac] V extends Object declared in method <K,V>unmodifiableMap(Map<? extends K,? extends V>)
[javac] where CAP#1,CAP#2 are fresh type-variables:
[javac] CAP#1 extends K from capture of ? extends K
[javac] CAP#2 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MapUtils.java:1537: error: incompatible types: SortedMap<K,CAP#1> cannot be converted to SortedMap<K,V>
[javac] return UnmodifiableSortedMap.unmodifiableSortedMap(map);
[javac] ^
[javac] where K,V are type-variables:
[javac] K extends Object declared in method <K,V>unmodifiableSortedMap(SortedMap<K,? extends V>)
[javac] V extends Object declared in method <K,V>unmodifiableSortedMap(SortedMap<K,? extends V>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/MultiSetUtils.java:85: error: incompatible types: MultiSet<CAP#1> cannot be converted to MultiSet<E>
[javac] return UnmodifiableMultiSet.unmodifiableMultiSet(multiset);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableMultiSet(MultiSet<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/PredicateUtils.java:537: error: incompatible types: Predicate<CAP#1> cannot be converted to Predicate<T>
[javac] return TransformedPredicate.transformedPredicate(transformer, predicate);
[javac] ^
[javac] where T is a type-variable:
[javac] T extends Object declared in method <T>transformedPredicate(Transformer<? super T,? extends T>,Predicate<? super T>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends T from capture of ? extends T
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/QueueUtils.java:56: error: incompatible types: Queue<CAP#1> cannot be converted to Queue<E>
[javac] return UnmodifiableQueue.unmodifiableQueue(queue);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableQueue(Queue<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:225: error: incompatible types: Set<CAP#1> cannot be converted to Set<E>
[javac] return UnmodifiableSet.unmodifiableSet(set);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>unmodifiableSet(Set<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:505: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E>
[javac] return IteratorUtils.filteredIterator(a.iterator(), notContainedInB);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>difference(Set<? extends E>,Set<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/SetUtils.java:543: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E>
[javac] return IteratorUtils.filteredIterator(a.iterator(), containedInB);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in method <E>intersection(Set<? extends E>,Set<? extends E>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:187: error: incompatible types: no instance(s) of type variable(s) I#1 exist so that Transformer<I#1,CAP#1> conforms to Transformer<I#2,O#2>
[javac] return FactoryTransformer.factoryTransformer(factory);
[javac] ^
[javac] where I#1,O#1,O#2,I#2 are type-variables:
[javac] I#1 extends Object declared in method <I#1,O#1>factoryTransformer(Factory<? extends O#1>)
[javac] O#1 extends Object declared in method <I#1,O#1>factoryTransformer(Factory<? extends O#1>)
[javac] O#2 extends Object declared in method <I#2,O#2>asTransformer(Factory<? extends O#2>)
[javac] I#2 extends Object declared in method <I#2,O#2>asTransformer(Factory<? extends O#2>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#2 from capture of ? extends O#2
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:235: error: incompatible types: Transformer<CAP#1,CAP#1> cannot be converted to Transformer<T,T>
[javac] return IfTransformer.ifTransformer(predicate, trueTransformer);
[javac] ^
[javac] where T is a type-variable:
[javac] T extends Object declared in method <T>ifTransformer(Predicate<? super T>,Transformer<? super T,? extends T>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends T from capture of ? extends T
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TransformerUtils.java:428: error: incompatible types: no instance(s) of type variable(s) I#1 exist so that Transformer<I#1,CAP#1> conforms to Transformer<I#2,O#2>
[javac] return MapTransformer.mapTransformer(map);
[javac] ^
[javac] where I#1,O#1,O#2,I#2 are type-variables:
[javac] I#1 extends Object declared in method <I#1,O#1>mapTransformer(Map<? super I#1,? extends O#1>)
[javac] O#1 extends Object declared in method <I#1,O#1>mapTransformer(Map<? super I#1,? extends O#1>)
[javac] O#2 extends Object declared in method <I#2,O#2>mapTransformer(Map<? super I#2,? extends O#2>)
[javac] I#2 extends Object declared in method <I#2,O#2>mapTransformer(Map<? super I#2,? extends O#2>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends O#2 from capture of ? extends O#2
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/TrieUtils.java:46: error: incompatible types: Trie<K,CAP#1> cannot be converted to Trie<K,V>
[javac] return UnmodifiableTrie.unmodifiableTrie(trie);
[javac] ^
[javac] where K,V are type-variables:
[javac] K extends Object declared in method <K,V>unmodifiableTrie(Trie<K,? extends V>)
[javac] V extends Object declared in method <K,V>unmodifiableTrie(Trie<K,? extends V>)
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/iterators/IteratorIterable.java:118: error: incompatible types: Iterator<CAP#1> cannot be converted to Iterator<E>
[javac] this.typeSafeIterator = createTypesafeIterator(this.iterator);
[javac] ^
[javac] where E is a type-variable:
[javac] E extends Object declared in class IteratorIterable
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends E from capture of ? extends E
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/collections4/multimap/TransformedMultiValuedMap.java:162: error: incompatible types: FluentIterable<CAP#1> cannot be converted to Iterable<V>
[javac] final Iterable<V> transformedValues = FluentIterable.of(values).transform(valueTransformer);
[javac] ^
[javac] where V is a type-variable:
[javac] V extends Object declared in class TransformedMultiValuedMap
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends V from capture of ? extends V
[javac] /var/lib/jenkins/jobs/Java-EarlyAccess-JOSM-Plugins/workspace/jdk/JDK9/apache-commons/src/org/apache/commons/imaging/util/Debug.java:125: error: incompatible types: ArrayList<CAP#1> cannot be converted to List<Object>
[javac] final List<Object> keys = new ArrayList<>(map.keySet());
[javac] ^
[javac] where CAP#1 is a fresh type-variable:
[javac] CAP#1 extends Object from capture of ?
[javac] 28 errors
[javac] 1 warning

generics, jdk9, josm-found

17/Oct/16 8:00 PM

3 years, 10 weeks, 2 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i30hcn:

Commons Collections

COLLECTIONS-470

TransformedMap class exists in two packages

Bug

Closed

Major

Fixed

Unassigned

Sebb

14/May/13 15:15

09/Nov/14 14:31

11/Jun/13 20:29

4.x

4.0-alpha1, 4.0

0

It's very confusing to have two different TransformedMap classes in different packages: map, splitmap.
Indeed the Test class has to take special care with the serialised file name to avoid a clash.

Since we can break binary compat in v4, now is the time to rename one of the classes.

Perhaps rename as follows:
splitmap/TransformedMap => splitmap/TransformedGetPutMap

14/May/13 6:38 PM

6 years, 41 weeks ago

327876

No Perforce job exists for this issue.

0

328220

0|i1kkkf:

Commons Collections

COLLECTIONS-519

private constructors in utility classes break existing code

Bug

Closed

Major

Won't Fix

Unassigned

Radoslav Paskalev

22/Apr/14 10:05

27/Nov/15 21:47

02/May/14 09:00

4.x

1

4

COLLECTIONS-276

Hello,

In collections version 4.x all utility classes (example ListUtils, MapUtils, PredicateUtils....) have private constructors. I consider this to be a serious bug, as it breaks any possibility the classes to be extended by the users. The javadoc says that constructors are private in order to prevent class instantiation but this object instantiation is not really problem and i think it is more important to allow classes to be extended. The possibility to extend utility classes was one of the major selling points of commons.lang and commons.collections projects. In the latest commons.lang project the utility classes still have public constructors.

Best Regards

22/Apr/14 3:03 PM

5 years, 46 weeks, 4 days ago

388053

No Perforce job exists for this issue.

0

388311

0|i1uui7:

Commons Collections

COLLECTIONS-372

ComparatorUtils.transformedComparator wrongly typed (generics)

Bug

Closed

Minor

Fixed

Unassigned

HaveNone

18/Mar/11 12:45

09/Nov/14 14:31

06/Mar/13 19:52

4.x

4.0-alpha1, 4.0

Comparator

1

0

COLLECTIONS-333

n/a

ComparatorUtils.transformedComparator is currently typed as follows :

{{public static <I,O> Comparator<O> transformedComparator(Comparator comparator, Transformer<I, O> transformer)}}

It should be typed as follows so that is can be used without removing generics typing:
{{public static <I,O> Comparator transformedComparator(Comparator<O> comparator, Transformer<I, O> transformer)}}

Here is a unit test for it :
Transformer<Integer, String> itosTransformer = TransformerUtils.stringValueTransformer();
Comparator<Integer> c = new Comparator<Integer>() {

@Override
public int compare(Integer o1, Integer o2) {
return o1.compareTo(o2);
}
};
Comparator<String> stringComparator = ComparatorUtils.transformedComparator(c, itosTransformer);

stringComparator.compare("string1", "string2");

patch

06/Mar/13 7:52 PM

7 years, 2 weeks, 6 days ago

18631

No Perforce job exists for this issue.

0

90356

0|i0ftdb:

Commons Collections

COLLECTIONS-447

TreeListIterator can return incorrect results after remove() is called

Bug

Closed

Major

Fixed

Unassigned

Jeffrey Barnes

03/Mar/13 03:24

09/Nov/15 20:53

04/Mar/13 20:20

Nightly Builds

3.2.2, 4.0-alpha1, 4.0

Collection

0

1

COLLECTIONS-433

Windows 7, jdk1.5.0_22

{{TreeList.TreeListIterator}} can get in a bad state when {{remove()}} is called, causing it to subsequently return incorrect results. This is because {{TreeListIterator}} caches an {{AVLNode}} reference in its field {{next}}, and this node reference may become stale when {{remove()}} is called (it may contain a reference to a node that no longer exists in the tree).

I will attach two patches: {{testcase.patch}} will contain a test case illustrating the bug, and {{fix.patch}} will contain a fix. (To fix the bug, I simply clear the cached {{next}} value in {{TreeListIterator.remove}}.)

This was originally reported in a comment to COLLECTIONS-433; I am creating a separate issue for this at Thomas Neidhart's suggestion.

patch, test

04/Mar/13 8:20 PM

7 years, 3 weeks, 1 day ago

315498

No Perforce job exists for this issue.

2

315842

0|i1ifxz:

Commons Collections

COLLECTIONS-414

Collections does not compile with openjdk 1.6.0_24

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

23/Jun/12 12:31

09/Nov/14 14:31

15/Jul/12 11:19

Nightly Builds

4.0-alpha1, 4.0

0

1

There are several classes for which generic type inference does not work when using the openjdk 1.6.0_24 compiler:

{noformat}
[ERROR] /home/tn/workspace/apache/commons-collections/src/main/java/org/apache/commons/collections/functors/OnePredicate.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments
[ERROR] required: org.apache.commons.collections.Predicate<? super java.lang.Object>[]
[ERROR] found: org.apache.commons.collections.Predicate<? super T>[]
{noformat}

This is mainly due to re-using a method argument that is restricted by Predicate<? super T> to assign methods results of type Predicate<T>.

The eclipse compiler does not report an error in these cases.

23/Jun/12 1:06 PM

7 years, 39 weeks, 3 days ago

292944

No Perforce job exists for this issue.

0

164346

0|i0shpj:

Commons Collections

COLLECTIONS-601

commons-collections unit tests broken in Java 8

Bug

Resolved

Major

Cannot Reproduce

Unassigned

Allon Mureinik

20/Mar/17 10:38

25/May/17 11:07

24/May/17 08:25

Nightly Builds

0

2

Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full details in attached logs

Building the upstream trunk (currently, patch 30b2aca) fails the unit tests in Java 8, but passes in Java 7 on the same machine. Attached logs with env details an errors of a successful Java 7 build and an unsuccessful Java 8 build

test

20/Mar/17 9:51 PM

2 years, 42 weeks, 5 days ago

9223372036854775807

No Perforce job exists for this issue.

2

9223372036854775807

0|i3ciav:

Commons Collections

COLLECTIONS-255

Unused variable in TreeBidiMap.java

Bug

Closed

Trivial

Fixed

Unassigned

Henri Yandell

08/Jun/07 00:32

09/Nov/14 14:31

28/Feb/13 19:55

Nightly Builds

4.0-alpha1, 4.0

BidiMap

0

Twice in TreeBidiMap there is an entrySet variable that is not used. Rather the entrySet() method returns a new TreeView every time.

We should either:

a) Delete the variable.
b) Use the variable and always return the same TreeView.

I'm thinking a).

[Found via http://opensource.fortifysoftware.com/ ]

08/Jun/07 12:36 PM

10 years, 13 weeks ago

18745

No Perforce job exists for this issue.

1

164468

0|i0sign:

Commons Collections

COLLECTIONS-135

[PATCH] SwitchTransformer doc/impl inconsistent

Bug

Closed

Trivial

Fixed

Unassigned

Matt Benson

05/Apr/06 05:38

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

TransformerUtils says that a null defaultTransformer will return null; this is
consistent with the switchTransformer tests under TestTransformerUtils.
However, the SwitchTransformer constructor's javadoc says that a null
defaultTransformer means nop, which is incorrect. Not that it matters, but NOP
would have been more intuitive IMHO, but what's done is done and passing
NOPTransformer.INSTANCE or TransformerUtils.nopTransformer() is no big deal.

11/Apr/06 6:23 AM

13 years, 51 weeks ago

18863

No Perforce job exists for this issue.

1

39207

164573

0|i0sj3z:

Commons Collections

COLLECTIONS-117

[collections][PATCH] correct misspelling in RELEASE-NOTES.html

Bug

Closed

Trivial

Fixed

Unassigned

Matt Benson

06/Jan/06 02:45

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

s/COMPATABILITY/COMPATIBILITY/

07/Jan/06 6:38 AM

14 years, 12 weeks, 3 days ago

18881

No Perforce job exists for this issue.

1

38140

164591

0|i0sj7z:

Commons Collections

COLLECTIONS-114

[collections] Build Warnings when building under JDK 1.5

Bug

Closed

Major

Fixed

Unassigned

Will Pugh

23/Jun/05 03:36

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

When I build under JDK 1.5 on MacOSX, I get a bunch of warnings. Almost all of
them are a result of some APIs moving over to using varargs. Here is an example
of some of the warnings. The fixes in just about all cases was to cast a null
to either (Method[]) or (Object[]). in one place a temporary array new String[]
{ ... } had to be changed to new Object[] { ... }

[javac] Compiling 271 source files to
/Users/willpugh/projects/beanutils2/collections2/collections/target/classes
/Users/willpugh/projects/beanutils2/collections2/collections/src/java/org/apache/commons/collections/functors/PrototypeFactory.java:62:
warning: non-varargs call of varargs method with inexact argument type for last
parameter;
cast to java.lang.Class for a varargs call
cast to java.lang.Class[] for a non-varargs call and to suppress this warning
Method method = prototype.getClass().getMethod("clone", null);
^
/Users/willpugh/projects/beanutils2/collections2/collections/src/java/org/apache/commons/collections/functors/PrototypeFactory.java:119:
warning: non-varargs call of varargs method with inexact argument type for last
parameter;
cast to java.lang.Class for a varargs call
cast to java.lang.Class[] for a non-varargs call and to suppress this warning
iCloneMethod = iPrototype.getClass().getMethod("clone", null);

. . .

26/Jun/05 1:41 AM

14 years, 40 weeks, 3 days ago

18884

No Perforce job exists for this issue.

1

35474

164594

0|i0sj8n:

Commons Collections

COLLECTIONS-68

[collections] Concurrent modification in FastArrayList

Bug

Closed

Major

Fixed

Unassigned

Guilhem Lavaux

01/May/05 03:11

15/Mar/08 21:35

14/Jul/06 12:04

Nightly Builds

1

0

Operating System: All
Platform: All

I confirm a bug highlighted by GNU Classpath internal checkings concerning
FastArrayList. It uses two different paths for modifying a list and accessing it
in FastArrayList$ListIter.remove.

On 2005-04-30 SVN snapshot the line which causes problem is at
org.apache.commons.collections.FastArrayList$ListIter.remove
(FastArrayList.java:1308)

because previousIndex() is used on an iterator which has not followed the
modification introduced by a call to List.remove.

This bug is not detected by Sun's JDK.

08/May/05 1:30 AM

13 years, 37 weeks, 4 days ago

18930

No Perforce job exists for this issue.

0

34690

164640

0|i0sjiv:

Commons Collections

COLLECTIONS-56

NoSuchElementException in ReferenceMap views

Bug

Closed

Major

Fixed

Unassigned

Joe Raysa

16/Dec/03 08:57

15/Mar/08 21:35

Nightly Builds

0

Operating System: All
Platform: PC

The keySet() and values() views for the
org.apache.commons.collections.map.ReferenceMap class will throw a
NoSuchElementException in their toArray(Object[]) methods if any keys or values
have been reclaimed by the garbage collector and purge() has not been invoked.
The toArray(Object[]) implementation inherited from
java.util.AbstractCollection uses size()-based iteration rather than hasNext()-
based iteration. This is inappropriate because the size of the map can change
during iteration. The problem is exacerbated by the fact that neither the
KeySet nor Values classes purge stale elements from the list in their size()
methods.

The attached test case reliably reproduces this exception with Sun's 1.3.1_07
and 1.4.2 Win2K Hotspot VMs.

The attached diff is a proposed fix for this issue.

29/Dec/03 11:37 PM

16 years, 14 weeks, 1 day ago

18942

No Perforce job exists for this issue.

2

25551

164652

0|i0sjlj:

Commons Collections

COLLECTIONS-97

[collections][PATCH] JavaDoc fixes for iterators

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

11/Sep/03 04:50

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch fixes three typos in ComparatorChain, FixedOrderComparator
and TransformingComparator.

17/Sep/03 3:42 PM

16 years, 28 weeks, 6 days ago

18901

No Perforce job exists for this issue.

1

23087

164611

0|i0sjcf:

Commons Collections

COLLECTIONS-25

[collections][PATCH] OutOfMemoryError test case for MapUtils.verbosePrint.

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

10/Sep/03 04:02

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch adds a test case to TestMapUtils that demonstrates infinite
recursion in MapUtils.verbosePrint.

10/Sep/03 5:02 AM

16 years, 28 weeks, 5 days ago

18973

No Perforce job exists for this issue.

2

23041

164683

0|i0sjsf:

Commons Collections

COLLECTIONS-136

[collections][PATCH] CollectionUtils.getFreq optimization

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

09/Sep/03 03:59

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch improves the performance of CollectionUtils.getFreq(Object,
Map) by using a test in place of a thrown exception.

The effect of the change was measured with the class below. These are the times
for the Sun JDK 1.4.1_03 on Red Hat Linux 8.0

pre-optimization: 122534
post-optimization: 104637

The patch reduced the time to run the test to 85% of the original.

The also patch removes a catch of NoSuchElementException which, as far as I can
tell, was unnecessary in the original code.

This is the test class:

import org.apache.commons.collections.CollectionUtils ;

import java.util.*;

public class CollectionUtilsTest {

Set a ;
Set b ;
Set c ;

Collection cols [] ;

long startMillis ;
void init () {

a = new HashSet () ;
for ( int i = 1 ; i <= 10000 ; i++ ) {
a.add ( new Integer ( i ) ) ;
}

b = new HashSet () ;
for ( int i = 5001 ; i <= 15000 ; i++ ) {
b.add ( new Integer ( i ) ) ;
}

c = new HashSet () ;
for ( int i = 10001 ; i <= 20000 ; i++ ) {
c.add ( new Integer ( i ) ) ;
}

cols = new Collection [] { a, b, c } ;

startMillis = System.currentTimeMillis () ;
}

void run () {

for ( int i = 0 ; i < 3 ; i++ ) {
for ( int j = 0 ; j < 3 ; j++ ) {
CollectionUtils.union ( cols [ i ], cols [ j ] ) ;
CollectionUtils.intersection ( cols [ i ], cols [ j ] ) ;
CollectionUtils.disjunction ( cols [ i ], cols [ j ] ) ;
CollectionUtils.subtract ( cols [ i ], cols [ j ] ) ;
}
}

}

void report () {

System.out.println ( "Elapsed millis: " + ( System.currentTimeMillis () -
startMillis ) ) ;
}

public static void main ( String [] arg ) {

CollectionUtilsTest t = new CollectionUtilsTest () ;

t.init () ;
t.run () ;
t.report () ;

}
}

10/Sep/03 4:56 AM

16 years, 29 weeks, 6 days ago

18862

No Perforce job exists for this issue.

1

23004

164572

0|i0sj3r:

Commons Collections

COLLECTIONS-58

[collections] [PATCH] patch to reduce object creation in CollectionUtils

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

08/Sep/03 05:29

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch reduces the number of Integer objects created when invoking
CollectionUtils.getCardinalityMap(final Collection col). The number of Integers
created is reduced by the count of unique objects within col.

The patch does not change the basic algorithm so the simplicity of the method is
not lost.

The change was profiled with the class below. These are the absolute times for
JDK 1.3.1_04 and 1.4.1_03

1.4 1.3
pre: 168267 153849
post: 164473 150866

and normalised to the pre version for each JDK

1.4 1.3
pre: 1.00 1.00
post: 0.98 0.98

so there was only a minor speed difference however the reduction in the number
of created objects has a memory use advantage. It was surprising to see that JDK
1.4.1 was slower than 1.3.1, in this limited test. The binaries were compiled
with JDK 1.4.1.

This is the test class:

import org.apache.commons.collections.CollectionUtils ;

import java.util.*;

public class CollectionUtilsTest {

Set a ;
Set b ;
Set c ;

Collection cols [] ;

long startMillis ;
void init () {

a = new HashSet () ;
for ( int i = 1 ; i <= 10000 ; i++ ) {
a.add ( new Integer ( i ) ) ;
}

b = new HashSet () ;
for ( int i = 5001 ; i <= 15000 ; i++ ) {
b.add ( new Integer ( i ) ) ;
}

c = new HashSet () ;
for ( int i = 1001 ; i <= 20000 ; i++ ) {
c.add ( new Integer ( i ) ) ;
}

cols = new Collection [] { a, b, c } ;

startMillis = System.currentTimeMillis () ;
}

void run () {

for ( int i = 0 ; i < 3 ; i++ ) {
for ( int j = 0 ; j < 3 ; j++ ) {
CollectionUtils.union ( cols [ i ], cols [ j ] ) ;
CollectionUtils.intersection ( cols [ i ], cols [ j ] ) ;
CollectionUtils.disjunction ( cols [ i ], cols [ j ] ) ;
CollectionUtils.subtract ( cols [ i ], cols [ j ] ) ;
}
}

}

void report () {

System.out.println ( "Elapsed millis: " + ( System.currentTimeMillis () -
startMillis ) ) ;
}

public static void main ( String [] arg ) {

CollectionUtilsTest t = new CollectionUtilsTest () ;

t.init () ;
t.run () ;
t.report () ;

}
}

10/Sep/03 4:28 AM

16 years, 29 weeks, 6 days ago

18940

No Perforce job exists for this issue.

1

22973

164650

0|i0sjl3:

Commons Collections

COLLECTIONS-125

[collections] [PATCH] MapUtils JavaDoc fixes

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

08/Sep/03 04:35

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch modifies some documentation tags and fixes the code example
for MapUtils.lazySortedMap.

10/Sep/03 4:08 AM

16 years, 29 weeks, 6 days ago

18873

No Perforce job exists for this issue.

1

22972

164583

0|i0sj67:

Commons Collections

COLLECTIONS-90

[collections][PATCH] JavaDoc simplification for CollectionUtils

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

07/Sep/03 08:40

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch removes some extraneous @return and @throws tags and makes
the effect of a null Predicate easier to understand for a couple of methods.

07/Sep/03 3:48 PM

16 years, 30 weeks, 2 days ago

18908

No Perforce job exists for this issue.

1

22964

164618

0|i0sjdz:

Commons Collections

COLLECTIONS-112

[collections] [PATCH] fixes some @author hrefs or removes the link markup

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

07/Sep/03 06:43

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The attached patches are mutually exclusive and either fix some hrefs in some
@author tags which are missing 'mailto:' prefixes or (to match a recently
applied collections patch) remove the link markup altogether.

07/Sep/03 3:51 PM

16 years, 30 weeks, 2 days ago

18886

No Perforce job exists for this issue.

2

22962

164596

0|i0sj93:

Commons Collections

COLLECTIONS-19

[collections] 'acknowledgement' typos in licence headers

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

31/Aug/03 08:58

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

The Apache Software License includes these typos in various files

'acknowlegement' in 54 files
'acknowledgment/acknowledgements' in 519 files

01/Sep/03 12:34 AM

16 years, 31 weeks, 2 days ago

18979

No Perforce job exists for this issue.

0

22845

164689

0|i0sjtr:

Commons Collections

COLLECTIONS-119

[collections] Misnamed method in FixedOrderComparator: getUnkownObjectBehavior

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

31/Aug/03 08:45

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The method is probably meant to be getUnknownObjectBehavior()

From the class:

FixedOrderComparator {

...

/**
* Gets the behavior for comparing unknown objects.
*/
public int getUnkownObjectBehavior() {
return unknownObjectBehavior;
}

...
}

31/Aug/03 9:40 PM

16 years, 31 weeks, 2 days ago

18879

No Perforce job exists for this issue.

0

22844

164589

0|i0sj7j:

Commons Collections

COLLECTIONS-47

[collections] [PATCH] fixes 97 typos

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

31/Aug/03 08:35

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch fixes 97 typos in the version of collections from 03-August-31.

31/Aug/03 8:13 PM

16 years, 31 weeks, 1 day ago

18951

No Perforce job exists for this issue.

1

22843

164661

0|i0sjnj:

Commons Collections

COLLECTIONS-54

[collections][PATCH] increase number of tests run from 2484 to 7429

Bug

Closed

Critical

Fixed

Unassigned

Janek Bogucki

14/Sep/03 04:29

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

The attached file patches build.xml to use 'TestAllPackages' instead of
'TestAll' for the value of 'test.entry'. This results in a greater number of
tests being run.

project.xml also uses 'TestAll' but there this patch does not fix that becuase I
am not using maven.

(I find this situation a bit odd because Stephen Colebourne mentioned that some
bugs had been detected in o.a.c.collections.observed package a few days ago by
some tests and as far as I can see those tests would not have run without this
change. Is the use of ant deprecated or am I just not seeing something obvious
or customary?)

17/Sep/03 3:36 PM

16 years, 28 weeks, 6 days ago

18944

No Perforce job exists for this issue.

1

23155

164654

0|i0sjlz:

Commons Collections

COLLECTIONS-20

[collections] TestObservedBag and TestObservedSet fail under Java 1.3.1

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

17/Sep/03 03:05

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

With CVS HEAD of 2003-Sept-16 two unit tests fail under Java 1.3.1_04.

$ java -version
java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)

The stack trace is:

[java] There were 2 failures:
[java] 1) testObservedSet(o.a.c.collections.observed.TestObservedBag)
junit.framework.AssertionFailedError: expected same:<7> was not:<6>
[java] at
o.a.c.collections.observed.ObservedTestHelper.doTestRemoveIterated(ObservedTestHelper.java:933)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedCollection(ObservedTestHelper.java:156)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedBag(ObservedTestHelper.java:188)
[java] at
o.a.c.collections.observed.TestObservedBag.testObservedSet(TestObservedBag.java:98)
[java] 2) testObservedSet(o.a.c.collections.observed.TestObservedSet)
junit.framework.AssertionFailedError: expected same:<7> was not:<6>
[java] at
o.a.c.collections.observed.ObservedTestHelper.doTestRemoveIterated(ObservedTestHelper.java:933)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedCollection(ObservedTestHelper.java:156)
[java] at
o.a.c.collections.observed.ObservedTestHelper.bulkTestObservedSet(ObservedTestHelper.java:164)
[java] at
o.a.c.collections.observed.TestObservedSet.testObservedSet(TestObservedSet.java:106)

[java] FAILURES!!!
[java] Tests run: 7489, Failures: 2, Errors: 0

It doesn't matter whether it is compiled with 1.4.1 or 1.3.1 as summarized here:

Run with:

1.3.1_04 1.4.1_03

Compiled with: 1.3.1_04 fail pass

1.4.1_03 fail pass

20/Sep/03 7:17 PM

16 years, 28 weeks, 3 days ago

18978

No Perforce job exists for this issue.

0

23201

164688

0|i0sjtj:

Commons Collections

COLLECTIONS-16

ExtendedProperties never sets isInitialized

Bug

Closed

Major

Fixed

Unassigned

Walt

18/Jan/03 06:16

15/Mar/08 21:35

14/Jul/06 12:05

Nightly Builds

1

0

Operating System: All
Platform: All

ExtendedProperties.isInitialized() is always false. The only code that sets it
is in a private init() function that is never called. Some other apps (Torque)
have depended on isInitialized being set to true after a load but apparently the
Torque devs never realized it wasn't.

I'll attach a patch to correct this. The patch removes the private, never used,
init() function and sets isInitialized on either a load() or addProperty().

25/Jan/03 8:23 PM

13 years, 37 weeks, 4 days ago

18982

No Perforce job exists for this issue.

1

16225

164692

0|i0sjuf:

Commons Collections

COLLECTIONS-1

[collections] Collections Javadoc warnings with JDK 1.4.2

Bug

Closed

Major

Fixed

Unassigned

Eric Johnson

09/Oct/03 00:57

18/Mar/20 02:33

14/Jul/06 05:48

Nightly Builds

3.0

0

Operating System: All
Platform: All

Numerous javadoc warnings when doing "ant dist" target under JDK 1.4.2. Partial
patch to follow

10/Oct/03 4:03 AM

14 years, 35 weeks, 5 days ago

18997

No Perforce job exists for this issue.

4

23680

164707

0|i0sjxr:

Commons Collections

COLLECTIONS-126

[patch] JDK 1.4.1 compil error / TestHashMap.java does not define makeEmptyMap() in org.apache.commons.collections.TestMap

Bug

Closed

Major

Incomplete

Unassigned

Jari Aalto

23/Jul/02 23:14

15/Mar/08 21:36

Nightly Builds

0

Operating System: All
Platform: PC

Environment:

Win32 W2kSp2 / cygwin
Win32 JDK 1.4.1
CVS ant
CVS jakarta-commons

There is problem with compiling. See attached patch, which I AM NOT
SURE if it is correct solution. At least it builds without this error.

- jari

root@W2KPICASSO:/cygdrive/d/java/apache/cvs/jakarta-commons/collections$ ant.bat
Buildfile: build.xml

init:

build-java:

build-test:
[javac] Compiling 62 source files to D:\java\apache\cvs\jakarta-
commons\collections\dist\classes
[javac] D:\java\apache\cvs\jakarta-
commons\collections\src\test\org\apache\commons\collections\TestHashMap.java:74:
org.apache.commons.collections.TestHashMap should be declared abstract; it
does not define makeEmptyMap() in org.apache.commons.collections.TestMap
[javac] public class TestHashMap extends TestMap
[javac] ^
[javac] 1 error

BUILD FAILED
file:d:/java/apache/cvs/jakarta-commons/collections/build.xml:216: Compile
failed; see the compiler error output for details.

Total time: 20 seconds

==========================================================================

root@W2KPICASSO:/cygdrive/d/java/apache/cvs/jakarta-commons/collections$ diff -
u src/test/org/apache/commons/collections/TestHashMap.java.orig
src/test/org/apache/commons/collections/TestHashMap.java
--- src/test/org/apache/commons/collections/TestHashMap.java.orig 2001-07-
15 01:33:28.000000000 +0300
+++ src/test/org/apache/commons/collections/TestHashMap.java 2002-07-23
13:45:34.000000000 +0300
@@ -94,6 +94,11 @@
return (hm);
}

+ public Map makeEmptyMap()
+ {
+ return makeMap();
+ }
+
protected HashMap map = null;

public void setUp()

10/Aug/02 7:56 AM

16 years, 41 weeks, 1 day ago

18872

No Perforce job exists for this issue.

1

11092

164582

0|i0sj5z:

Commons Collections

COLLECTIONS-41

LazyCollections.lazyList.get(i) grows wrong

Bug

Closed

Major

Fixed

Unassigned

Nikolaj Joergensen

07/Aug/02 13:39

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

LazyCollections.lazyList.get(i) grows wrong when called with i == (size() -1).

If the list has 3 elements and LazyCollections.lazyList.get(2) is called then
size of the list will grow to size == 4 because within bounds check says:

if(index < (this.listImpl.size()-1) {

Should be:

if(index < this.listImpl.size()) {

13/Aug/02 7:33 AM

17 years, 34 weeks ago

18957

No Perforce job exists for this issue.

1

11522

164667

0|i0sjov:

Commons Collections

COLLECTIONS-9

[collections] ~20 Javadoc fixes and type cast clean ups.

Bug

Closed

Major

Fixed

Unassigned

Gary D. Gregory

ggregory@seagullsw.com

07/Jan/04 07:27

10/Mar/11 23:16

15/Mar/08 21:35

Nightly Builds

0

Operating System: All
Platform: All

Please see patch file attached.

07/Jan/04 7:28 AM

16 years, 12 weeks, 4 days ago

18989

No Perforce job exists for this issue.

1

25936

164699

0|i0sjvz:

Commons Collections

COLLECTIONS-78

BinaryHeap.remove(Object) seems to break heap order

Bug

Closed

Major

Fixed

Unassigned

Steve Phelps

30/Dec/03 16:46

15/Mar/08 21:36

Nightly Builds

0

Operating System: Linux
Platform: PC

I am currently attempting to migrate from my own implementation of a BinaryHeap
to the implementation in org.apache.commons.collections.BinaryHeap.

I have some existing unit tests for my implementation which fail when I run them
on the commons BinaryHeap. Below is source-code for the JUnit test which fails.
The test 'testRandom' is the test that fails. This test creates heaps
initialised with 100 randomly generated Integers and proceeds to add and remove
random elements from these heaps and then checks the heap order. Some of the
elements that are removed may not exist in the heap. Heap order is checked by
disassembling the heap using BinaryHeap.pop() and ensuring that subsequent
elements are >= earlier elements.

The problem appears to be related to the BinaryHeap.remove(Object) method-- if
this is commented out the test succeeds. It may be the case that the problem
occurs when non-existant elements are removed, but I have not attempted to
verify this.

---------
BinaryHeapTest.java
---------
/*
* JASA Java Auction Simulator API
* Copyright (C) 2001-2003 Steve Phelps
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details.
*/

package test.uk.ac.liv.util;

import test.uk.ac.liv.PRNGTestSeeds;

import junit.framework.*;

//import uk.ac.liv.util.*;

import org.apache.commons.collections.BinaryHeap;

import java.util.Random;
import java.util.Iterator;
import java.util.LinkedList;

public class BinaryHeapTest extends TestCase {

BinaryHeap h1;

public BinaryHeapTest( String name ) {
super(name);
}

public void setUp() {

h1 = new BinaryHeap();

h1.insert(new Integer(1));
h1.insert(new Integer(3));
h1.insert(new Integer(9));
h1.insert(new Integer(3));
h1.insert(new Integer(5));
h1.insert(new Integer(7));
}

public void test() {
System.out.println("h1 = " + h1);
assertTrue( h1.contains(new Integer(3)) );
assertTrue( h1.contains(new Integer(9)) );
assertTrue( h1.contains(new Integer(1)) );
assertTrue( h1.contains(new Integer(5)) );
assertTrue( !h1.contains(new Integer(10)) );
assertTrue( !h1.contains(new Integer(-1)) );
Object x = h1.pop();
System.out.println("h1 after removing first = " + h1);
checkOrder(h1);
assertTrue( ((Integer) x).equals(new Integer(1)));
assertTrue( !h1.contains(new Integer(1)) );
assertTrue( h1.contains(new Integer(3)) );
assertTrue( h1.contains(new Integer(9)) );
assertTrue( h1.contains(new Integer(5)) );
h1.remove(new Integer(9));
System.out.println("h1 after removing 9 = " + h1);
assertTrue( h1.contains(new Integer(3)) );
assertTrue( !h1.contains(new Integer(9)) );
assertTrue( h1.remove( new Integer(3) ) );
System.out.println("h1 after removing 3 = " + h1);
// assertTrue( ! h1.contains(new Integer(3)) );
x = h1.pop();
System.out.println("h1 after removing first = " + h1);
h1.pop();
System.out.println("h1 after removing first = " + h1);
assertTrue( h1.remove( new Integer(7) ) );
System.out.println("h1 after removing 7 = " + h1);
assertTrue( h1.isEmpty() );
assertTrue( ! h1.remove( new Integer(7) ) );
h1.add( new Integer(666) );
h1.add( new Integer(667) );
assertTrue( h1.remove(new Integer(667)) );
assertTrue( h1.size() == 1 );
assertTrue( ! h1.contains(new Integer(667)) );
assertTrue( h1.remove(new Integer(666)) );

}

public void checkOrder( BinaryHeap h ) {
System.out.println("Checking order of " + h);
Integer lastNum = null;
LinkedList l = new LinkedList();
while ( !h.isEmpty() ) {
Integer num = (Integer) h.pop();
System.out.println(num);
if ( lastNum != null && num.intValue() < lastNum.intValue() ) {
System.out.println("!!??*** " + num + " smaller than " + lastNum);
}
assertTrue( lastNum == null || num.intValue() >= lastNum.intValue() );
lastNum = num;
l.add(num);
}
Iterator it = l.iterator();
while ( it.hasNext() ) {
h.add( it.next() );
}
}

public void testRandom() {
Random randGenerator = new Random(PRNGTestSeeds.UNIT_TEST_SEED);
for( int i=0; i<1000; i++ ) {
BinaryHeap h = new BinaryHeap();
for( int r=0; r<100; r++ ) {
h.add( new Integer( randGenerator.nextInt(100)) );
}
System.out.println("Starting with heap " + h);
for( int r=0; r<20; r++ ) {
System.out.println("Attempting to remove " + r);
System.out.println("result = " + h.remove( new Integer(r) ) );
Integer n = new Integer( randGenerator.nextInt(100) );
System.out.println("Adding " + n);
h.add(n);
}
checkOrder(h);
}
}

public static void main( String[] args ) {
junit.textui.TestRunner.run (suite());
}

public static Test suite() {
return new TestSuite(BinaryHeapTest.class);
}

}

/*
* JASA Java Auction Simulator API
* Copyright (C) 2001-2003 Steve Phelps
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU General Public License for more details.
*/

-------
PRNGTestSeeds.java
-------

package test.uk.ac.liv;

/**
* The PRNG seed to use for deterministing unit-testing of seedable classes.
* This was introduced for ecj10, which uses a seed based on the
* current system time when using the null argument constructor.
*
* @author Steve Phelps
* @version $Revision: 1.2 $
*/

public class PRNGTestSeeds {

/**
* The seed to use for all unit tests.
*/
public static final long UNIT_TEST_SEED = 1465187;

}

31/Dec/03 7:47 AM

16 years, 13 weeks, 4 days ago

18920

No Perforce job exists for this issue.

0

25818

164630

0|i0sjgn:

Commons Collections

COLLECTIONS-60

Minor problems in SequencedHashMap and LRUMap

Bug

Closed

Major

Fixed

Unassigned

Paul Jack

09/Jun/02 04:42

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

1. The remove(Object) methods in the keySet and entrySet correctly remove null
keys, but incorrectly return false after they do so.

2. The retainAll(Collection) and removeAll(Collection) methods in the
collection views do not properly modify the map's modCount, and thus will never
cause a ConcurrentModificationException.

09/Jun/02 2:15 PM

17 years, 43 weeks, 2 days ago

18938

No Perforce job exists for this issue.

0

9719

164648

0|i0sjkn:

Commons Collections

COLLECTIONS-99

[PATCH] Apidoc fix for MapUtils.java

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

20/Jun/03 07:36

15/Mar/08 21:36

Nightly Builds

0

Operating System: All
Platform: All

This patch fixes two {@link} tags.

20/Jun/03 2:53 PM

16 years, 41 weeks, 4 days ago

18899

No Perforce job exists for this issue.

1

20933

164609

0|i0sjbz:

Commons Collections

COLLECTIONS-57

Addition of static class modifer to inner classes

Bug

Closed

Minor

Fixed

Unassigned

Janek Bogucki

20/Jun/03 06:56

15/Mar/08 21:35

Nightly Builds

0

Operating System: All
Platform: All

findbugs 0.6.0 suggested that these classes had inner classes which could be
made static

CursorableLinkedList.java
DefaultMapBag.java
ExtendedProperties.java
StaticBucketMap.java

The attached patch file patches these classes in that way. After patching the
unit test passed okay.

I'm assuming the unit tests passing is proof enough that these changes are okay.

20/Jun/03 3:00 PM

16 years, 41 weeks, 4 days ago

18941

No Perforce job exists for this issue.

1

20931

164651

0|i0sjlb:

Commons Collections

COLLECTIONS-4

Calling CollectionUtils.cardinality with null obj argument leads to NPE

Bug

Closed

Major

Fixed

Unassigned

Serhiy Yevtushenko

20/Oct/02 03:27

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

There is a bug in cardinality method, which shows, when obj parameter is null;
It leads to NullPointerException.

In order to reveal it, add line

assertEquals(0, CollectionUtils.cardinality(null, _b));

to testCardinality in TestCollectionUtils.

One variant of correct implementation is following:

public static int cardinality(Object obj, final Collection col) {
int count = 0;
Iterator it = col.iterator();
if(null==obj){
while(it.hasNext()){
Object elt = it.next();
if(null==elt){
count++;
}
}
}else{
while(it.hasNext()) {
Object elt = it.next();
if(obj.equals(elt)) {
count++;
}
}
}
return count;
}

02/Nov/02 3:55 AM

17 years, 22 weeks, 3 days ago

18994

No Perforce job exists for this issue.

0

13785

164704

0|i0sjx3:

Commons Collections

COLLECTIONS-34

Collections doesn't build with jdk1.2 javac

Bug

Closed

Major

Fixed

Unassigned

Jeff Turner

12/May/01 05:46

15/Mar/08 21:35

Nightly Builds

0

Operating System: Linux
Platform: PC

Hi,

Just tried building jakarta-commons/collections from CVS (12/5), and it doesn't
compile with Sun's 'javac' for linux:

$ java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2_007, green threads, nojit)

$ ant clean ; ant
....
build-java:
[mkdir] Created dir:
/home/jeff/apache/jakarta/jakarta-commons/collections/dist/classes
[javac] Compiling 26 source files to
/home/jeff/apache/jakarta/jakarta-commons/collections/dist/classes
[javac]
/home/jeff/apache/jakarta/jakarta-commons/collections/src/java/org/apache/commons/collections/FastTreeMap.java:325:
Inner type Entry in class java.util.TreeMap not accessible from class
org.apache.commons.collections.FastTreeMap.
[javac] Entry e = (Entry) i.next();
[javac] ^
[javac]
....
BUILD FAILED

However, it *does* work if I set build.compiler=jikes. It also works if I use
jdk1.3 'javac'. Possibly a bug in javac?

Anyway, just thought I'd bring this to people's attention, as the STATUS.html
file states it needs "JDK1.2 or later".

thanks,

--Jeff

18/May/01 12:20 AM

18 years, 46 weeks, 5 days ago

18964

No Perforce job exists for this issue.

0

1729

164674

0|i0sjqf:

Commons Collections

COLLECTIONS-31

[collections][PATCH] BlockingBuffer JavaDoc improvement

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

18/Sep/03 07:13

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch improvements the JavaDoc for
o.a.c.c.decorators.BlockingBuffer by describing the behaviour of get() and
remove() in a multithreaded environment.

18/Sep/03 12:12 PM

16 years, 28 weeks, 5 days ago

18967

No Perforce job exists for this issue.

1

23234

164677

0|i0sjr3:

Commons Collections

COLLECTIONS-89

[collections][PATCH] TestBlockingBuffer extensions and BlockingBuffer fix

Bug

Closed

Major

Fixed

Unassigned

Janek Bogucki

18/Sep/03 06:31

15/Mar/08 21:36

Nightly Builds

0

Operating System: other
Platform: Other

The attached patch adds some tests to assert the behaviour of
BlockingBuffer.get()/remove()/add()/addAll in various combinations.

The discussion that led to this patch can be found at COM-816.

Also attached is a patch to change notify() to notifyAll() in BlockingBuffer
which allows the tests in TestBlockingBuffer to pass.

18/Sep/03 12:14 PM

16 years, 28 weeks, 5 days ago

18909

No Perforce job exists for this issue.

2

23232

164619

0|i0sje7:

Commons Collections

COLLECTIONS-44

Upgrade your version number

Bug

Closed

Minor

Fixed

Unassigned

Arnaud HERITIER

11/Jul/02 21:05

15/Mar/08 21:35

Nightly Builds

0

Operating System: other
Platform: Other

Can you update your build xml to modify the component.version property.
It is actually setted to 2.0 and should be to 3.0 dev or 2.1 dev ??

Futhermore, the Manifest file is not automatically generated from build.xml
properties.

I attach a copy of the build.xml and the Manifest files that I modified to
automatically update the release number.

I let you to choose which number to use in the build.xml.

Here are diffs that I done from Cygwin because I can't access to the CVS
Repository from my office :-(

diff MANIFEST.MF :

5c5
< Implementation-Version: @version@
---
> Implementation-Version: 2.0

diff build.xml :

97,99d96
< <echo message="-------- ${Name-Long} ${component.version} --------"/>
< <filter token="version" value="${component.version}"/>
<
254,256c251
< <mkdir dir="${workdir}/classes"/>
< <mkdir dir="${workdir}/conf"/>
< <copy todir="${workdir}/classes">
---
> <copy todir="${workdir}">
261,263d255
< <copy todir="${workdir}/conf" filtering="on">
< <fileset dir="${source.src}/conf" includes="*.MF"/>
< </copy>
268c260
< <jar jarfile="${dest.jardir.jar}"
manifest="${workdir}/conf/MANIFEST.MF">
---
> <jar jarfile="${dest.jardir.jar}"
manifest="${source.src}/conf/MANIFEST.MF">

25/Nov/02 3:48 AM

17 years, 19 weeks, 1 day ago

18954

No Perforce job exists for this issue.

0

10686

164664

0|i0sjo7:

Commons Collections

COLLECTIONS-35

[collections] IteratorChain.hasNext() throws when chain is empty

Bug

Closed

Major

Fixed

Unassigned

Phil Steitz

08/Nov/03 12:22

15/Mar/08 21:35

14/Jul/06 12:05

Nightly Builds

1

0

Operating System: other
Platform: Other

If added to TestIteratorChain, the following test case fails with the stack
trace that follows. The exception is documented in the javadoc for
IteratorChain.hasNext(), but the behavior may be inconsistent with the Iterator
interface spec.

Test case:

public void testEmptyChainHasNext() {
IteratorChain chain = new IteratorChain();
assertTrue(!chain.hasNext());
}

Stack trace:

[java] Time: 20.733
[java] There was 1 error:
[java] 1)
testEmptyChainHasNext(org.apache.commons.collections.iterators.TestIteratorChain)
java.lang.UnsupportedOperationException: IteratorChains must contain at least
one Iterator
[java] at
org.apache.commons.collections.iterators.IteratorChain.checkChainIntegrity(IteratorChain.java:248)
[java] at
org.apache.commons.collections.iterators.IteratorChain.lockChain(IteratorChain.java:256)
[java] at
org.apache.commons.collections.iterators.IteratorChain.hasNext(IteratorChain.java:295)
[java] at
org.apache.commons.collections.iterators.TestIteratorChain.testEmptyChainHasNext(TestIteratorChain.java:186)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

30/Dec/03 12:08 AM

13 years, 37 weeks, 4 days ago

18963

No Perforce job exists for this issue.

0

24520

164673

0|i0sjq7:

Commons Collections

COLLECTIONS-714

PatriciaTrie ignores trailing null characters in keys

Bug

Open

Critical

Unresolved

Unassigned

Rohan Padhye

30/Apr/19 23:11

18/Mar/20 02:34

04/Nov/19 06:38

4.3

Collection, Map

0

4

0

1800

In Java, strings are not null terminated. The string "x" (of length = 1 char) is different from the string "x\u0000" (of length = 2 chars). However, PatriciaTrie does not seem to distinguish between these strings.

To reproduce:
{code:java}
public void testNullTerminatedKey1() {
Map<String, Integer> map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u0000", 1); // key of length 2
map.put("x\u0000y", 2); // key of length 3
Assert.assertEquals(3, map.size()); // ok, 3 distinct keys

PatriciaTrie<Integer> trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size()); // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u0000" and "x\u0000y". The key "x" gets overwritten. Here is another way to repro the bug:
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie<Integer> trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u0000", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key "x\u0000" is inserted.

The PatriciaTrie docs do not mention anything about null-terminated strings. In general, I believe this also breaks the JDK Map contract since the keys "x".equals("x\u0000") is false.

This bug was found automatically using JQF: [https://github.com/rohanpadhye/jqf].

100%

1800

0

05/Jul/19 3:29 PM

20 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

https://github.com/apache/commons-collections/pull/78

0|z02alk:

Commons Collections

COLLECTIONS-697

JavaDoc for FixedSizeList should warn that modifying underlying list is still allowed and is not prevented

Bug

Resolved

Major

Fixed

Unassigned

Ranjan George

02/Oct/18 17:33

18/Mar/20 02:59

11/Jan/20 23:54

11/Jan/20 23:42

4.4

4.5

0

2

I just noticed that it is not explicitly mentioned in the JavaDoc that modifying the underlying list of a FixedSizeList would actually land up modifying the list of the constructed FixedSizeList. Not sure if this was by design, but at the very list I think the JavaDoc should caution against this.

Following is a test case that written that you could use to check this.

{code:java}

public void testAllowsMutationOfUnderlyingCollection() {

List<String> decoratedList = new ArrayList<>();
decoratedList.add("item 1");
decoratedList.add("item 2");
//
FixedSizeList<String> fixedSizeList = FixedSizeList.fixedSizeList(decoratedList);
int sizeBefore = fixedSizeList.size();
//
boolean changed = decoratedList.add("New Value");
Assert.assertTrue(changed);
//
Assert.assertEquals("Modifying an the underlying list is allowed", sizeBefore + 1, fixedSizeList.size());
}

{code}

02/Oct/18 5:48 PM

9 weeks, 3 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3yqvb:

Commons Collections

COLLECTIONS-747

MultiKey.getKeys class cast exception

Bug

Resolved

Major

Fixed

Gary D. Gregory

Walter Laan

10/Feb/20 14:49

17/Feb/20 09:00

16/Feb/20 21:28

4.4

4.5

KeyValue

0

2

When using an non-array constructor of MultiKey, an Object[] is created, which cannot be cast to a K[]
{code}
import org.apache.commons.collections4.keyvalue.MultiKey;

public class MultiKeyClassCastException {

public static void main(String[] args) {
MultiKeyClassCastException key1 = new MultiKeyClassCastException();
MultiKeyClassCastException key2 = new MultiKeyClassCastException();
MultiKeyClassCastException[] keys = new MultiKey<>(key1, key2).getKeys();
}
}

// running gives (same error if in module):

Exception in thread "main" java.lang.ClassCastException: class [Ljava.lang.Object; cannot be cast to class [LMultiKeyClassCastException; ([Ljava.lang.Object; is in module java.base of loader 'bootstrap'; [LMultiKeyClassCastException; is in unnamed module of loader 'app')
at MultiKeyClassCastException.main(MultiKeyClassCastException.java:8)
{code}

AFAIK, the only way to fix this (with source compatibility), is to only have a varargs constructors. but I think this breaks binary compatibility though and cannot be used with the existing constructors.
{code}
@SafeVarargs
public MultiKey(K... keys) {
this.keys = keys;
}
{code}

Workaround is to use array constructor with correct typed array or {code}Object[] keys = multiKey.getKeys();{code} explicitly.

11/Feb/20 7:29 AM

4 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z0bbwg:

Commons Collections

COLLECTIONS-741

Signature of IteratorUtils.objectGraphIterator is wrong

Bug

Open

Minor

Unresolved

Unassigned

Hans-Peter Stoerr

10/Dec/19 19:30

10/Dec/19 20:12

4.4

0

1

With the current signature

Iterator<E> objectGraphIterator(E root, Transformer<? super E,? extends E> transformer)

it is impossible to create any other iterator than an Iterator<Object> since the signature for the transformer just doesn't fit. (This problem extends to the underlying [ObjectGraphIterator|https://commons.apache.org/proper/commons-collections/javadocs/api-4.4/org/apache/commons/collections4/iterators/ObjectGraphIterator.html], too.) In the [example from the javadoc|https://commons.apache.org/proper/commons-collections/javadocs/api-4.4/org/apache/commons/collections4/IteratorUtils.html#objectGraphIterator-E-org.apache.commons.collections4.Transformer-], you would want to return an Iterator<Leaf>, but the root is of type Forest (compare the full source in the [ObjectGraphIteratorTest|https://git-wip-us.apache.org/repos/asf?p=commons-collections.git;a=blob;f=src/test/java/org/apache/commons/collections4/iterators/ObjectGraphIteratorTest.java;h=caff4ed312400c2a9e397c55edff2a5839981a68;hb=HEAD] ), the transformer takes either Forest, Tree, Branch or Leaf as argument and returns Leaf or Iterators of Tree, Branch or Leaf. There just is no common bound for these types except Object. I'm afraid there is no way to get some type safety into this signature. So I suggest to just relax it to

public static <E> Iterator<E> objectGraphIterator(final Object root, final Transformer<Object, Object> transformer)

since Object is the bound for all those arguments, anyway. (In many cases you would have the root and the first type variable the same type E, but the second type variable of the transformer would have to allow for both E and Iterator<E>, and thus be Object. So I'm not sure whether it makes any sense to make any restriction here.)

BTW: While that function has been useful for me, I'm a bit unhappy with it, anyway, since I see no acceptable way to use it to return all nodes of a tree, including the inner nodes, with it. At least not without serious hacks like wrapping the returned nodes in an Object[1] array and chain that to the children iterator.

14 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z09j88:

Commons Collections

COLLECTIONS-727

A potential misleading comment

Bug

Closed

Major

Fixed

Unassigned

XiangzheXu

20/Aug/19 15:20

23/Aug/19 20:17

23/Aug/19 20:15

4.4

4.5

Iterator

0

2

300

0%

I was wondering whether there's something wrong in the @throws IndexOutOfBoundsException condition for the `setIterator(final int index, final Iterator<? extends E> iterator)` method in the class `org.apache.commons.collections4.iterators.CollatingIterator<E>`.

The method and its Javadoc comment are shown as follows.

/**
* Sets the iterator at the given index.
*
* @param index index of the Iterator to replace
* @param iterator Iterator to place at the given index
* @throws IndexOutOfBoundsException if index < 0 or index > size()
* @throws IllegalStateException if iteration has started
* @throws NullPointerException if the iterator is null
*/
public void setIterator(final int index, final Iterator<? extends E> iterator) {
checkNotStarted();
if (iterator == null) {
throw new NullPointerException("Iterator must not be null");
}
iterators.set(index, iterator);
}

The boundary of the parameter index is marked as `index < 0 or index > size()`
in the comment.
Nevertheless, the `set(index, iterator)` method would throw an IndexOutOfBoundsException when the index is equal to `size()`.
So it would be better if we could change the boundary in the comment to `index < 0 or index >= size()`.

0%

300

JavaDoc

21/Aug/19 11:50 PM

29 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z05ubs:

Commons Collections

COLLECTIONS-756

CollectionUtils.filter(..) broken with blank Collections.singleton

Bug

Closed

Major

Not A Problem

Unassigned

noname713705

08/Mar/20 22:20

18/Mar/20 02:47

08/Mar/20 23:29

4.4

Collection

0

1

When using {{CollectionUtils.filter(..)}}, if the passed collection is initialized with jdk {{Collections.singleton(..)}} and only contains an {{isBlank(..)}} string, the method will throw an exception instead of removing blank item as expected. Tested with commons-collections:4.4 and java8.

All can be resumed with
{code:java}
CollectionUtils.filter(Collections.singleton(" "), StringUtils::isNotBlank); {code}

08/Mar/20 11:29 PM

1 week, 2 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z0cb60:

Commons Collections

COLLECTIONS-603

Small improvements for generics, conditional statements, and warnings suppressions

Bug

Resolved

Minor

Fixed

Bruno P. Kinoshita

24/May/17 08:02

24/May/17 08:21

4.2

Collection

0

1

Place holder for pull request #17

2 years, 42 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

Patch

0|i3fe67:

Commons Collections

COLLECTIONS-602

Improve efficiency of DefaultedMap.get

Bug

Resolved

Major

Fixed

Bruno P. Kinoshita

John Mark

19/May/17 14:23

24/May/17 09:35

4.2

0

2

The current implementation of {{org.apache.commons.collections4.map.DefaultedMap.get()}} is inefficient since it always require two map lookups. There is no need to check map.containsKey() every time. I would suggest implementing this method similar to the way that Java 8 does with {{Map.getOrDefault()}}. My proposed implementation would be something like this:

{code}
public V get(final Object key) {
V v;
return ((v = map.get(key) != null) || map.containsKey(key)) ? v : value.transform((K) key);
}
{code}

It can be further optimized to not even call map.containsKey() if map is known to not contain null values.

help-wanted

19/May/17 11:43 PM

2 years, 42 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

0|i3f84f:

Commons Collections

COLLECTIONS-679

MultiValuedMap JavaDoc Typo

Bug

Resolved

Trivial

Fixed

Unassigned

David Mollitor

16/Mar/18 19:02

25/Sep/19 14:47

4.5

0

2

0

1200

https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35

The example code provided refers to a class called _MultiValuedHashMap_. There is no such class in Commons Collection4. Perhaps _ArrayListValuedHashMap_ is a better example.

100%

1200

0

04/Apr/18 4:23 PM

24 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3rf87:

Commons Collections

COLLECTIONS-662

Build failures when building with Java 9

Bug

Resolved

Major

Fixed

Pascal Schumacher

Vamsi

12/Oct/17 04:12

20/Oct/17 16:33

20/Oct/17 14:09

0

4

*mvn clean test* fails with following errors when using with java-9
{code:java}
Tests in error:
MapUtilsTest.testgetByteValue:1051 » ServiceConfiguration sun.util.locale.prov...
MapUtilsTest.testgetDoubleValue:956 » ServiceConfiguration sun.util.locale.pro...
MapUtilsTest.testgetFloatValue:974 » ServiceConfiguration sun.util.locale.prov...
MapUtilsTest.testgetIntValue:1012 » ServiceConfiguration sun.util.locale.provi...
MapUtilsTest.testgetLongValue:992 » ServiceConfiguration sun.util.locale.provi...
MapUtilsTest.testgetShortValue:1031 » ServiceConfiguration sun.util.locale.pro...
ListIteratorWrapperTest.testRemove:116 » ServiceConfiguration sun.util.locale....

Tests run: 16088, Failures: 0, Errors: 7, Skipped: 0
{code}

12/Oct/17 4:16 AM

2 years, 21 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3l60v:

Commons Collections

COLLECTIONS-685

IterableUtils has public constructor

Bug

Open

Trivial

Unresolved

Unassigned

Stephan Fuhrmann

12/Jun/18 06:04

12/Jun/18 21:48

5.0

Collection

0

4

IterableUtils has public constructor. All other Utils classes have their constructor made private to prohibit instantiation.

12/Jun/18 6:07 AM

1 year, 40 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3urb3:

Commons Collections

COLLECTIONS-716

Don't include email address in Exception messages

Bug

Closed

Major

Fixed

Unassigned

Sebb

12/May/19 12:42

05/Jul/19 15:26

4.4

0

There are several messages in LRUMap which reference dev@commons.

These need to be replaced, see:

https://lists.apache.org/thread.html/5c3805daf30768034ae18576b7275b0535b4e5aec839cd13de2103c1@%3Cdev.commons.apache.org%3E

05/Jul/19 3:26 PM

36 weeks, 4 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z02lz4:

Commons Collections

COLLECTIONS-683

README.md contains pointer to non-existing Maven artifact/javadoc

Bug

Open

Minor

Unresolved

Unassigned

Stephan Fuhrmann

11/Jun/18 16:47

13/Jun/18 08:12

0

2

COLLECTIONS-682

The README.md file contains references to the
* 4.2 maven artefact on maven central (see XML snippet)
* 4.2 Javadoc on javadoc.io (see badge)

These pointers do not exist and confuse the developers.

The current version in fact is 4.1.

11/Jun/18 10:52 PM

1 year, 40 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3uqj3:

Commons Collections

COLLECTIONS-682

README.md contains unresolved template references

Bug

Closed

Trivial

Fixed

Unassigned

Stephan Fuhrmann

11/Jun/18 16:43

12/Jun/18 21:40

11/Jun/18 22:51

4.2

0

1

COLLECTIONS-683

https://github.com/apache/commons-collections/blob/master/README.md

The README.md file contains an unresolved reference to

{{${project.description}}}

11/Jun/18 10:51 PM

1 year, 40 weeks ago

9223372036854775807

No Perforce job exists for this issue.

1

9223372036854775807

0|i3uqi7:

Commons Collections

COLLECTIONS-680

CollectionUtilsTest test for collect is broken

Bug

Resolved

Major

Fixed

Unassigned

Konstantinos Angelopoulos

24/Apr/18 15:08

12/Jun/18 21:50

Collection

0

2

Cannot resolve method ConnectionUtils.collect in line 1289.

12/Jun/18 5:21 AM

1 year, 40 weeks ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3syjb:

Commons Collections

COLLECTIONS-686

Coveralls.io set to wrong branch?

Bug

Open

Trivial

Unresolved

Unassigned

Stephan Fuhrmann

13/Jun/18 17:40

0

1

[https://coveralls.io/github/apache/commons-collections?branch=master]

[https://coveralls.io/github/apache/commons-collections]

According to

[https://coveralls.io/github/apache/commons-collections]

the default branch is *trunk* and has 85% coverage (last commit June 2017). But the real working github branch is *master* and has 87% coverage.

This is why the coveralls badge on Github shows 85% I guess. I suggest switching the default branch on coveralls from trunk to master.

1 year, 39 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3utqn:

Commons Collections

COLLECTIONS-663

Unexpected ConcurrentModificationException when altering Collection of a MultiValuedMap

Bug

Open

Trivial

Unresolved

Bruno P. Kinoshita

Christophe Schmaltz

04/Nov/17 17:38

06/Nov/19 07:23

0

4

0

600

Testcase:
{code} @Test
public void test() {
MultiValuedMap<Integer, Integer> multiMap = new HashSetValuedHashMap<>();
multiMap.put(1, 10);
multiMap.put(2, 20);
for (Collection<Integer> innerCollection : multiMap.asMap().values()) {
for (Iterator<Integer> iterator = innerCollection.iterator(); iterator.hasNext();) {
Integer i = iterator.next();
iterator.remove(); // only the innerCollection is altered
}
// innerCollection.add(6); // adding stuff back should also work...
}
}{code}
This test unexpectedly throws a ConcurrentModificationException.
The issue is that when calling {{iterator.remove()}} the {{AbstractMultiValuedMap.ValuesIterator}} detects that the Collection is empty and calls {{AbstractMultiValuedMap.this.remove(key);}}.

It may be better if the iterator of the inner collection had a reference on the iterator if the outer map and called {{containerIterator.remove()}} instead.
*Note:* this solution would again present issues if the user tries to add new elements in this now empty collection (which was removed from the parent).

In the current state, it is quite unclear why an exception is thrown, without debugging the code.

100%

600

0

05/Nov/17 3:21 AM

18 weeks, 6 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i3meo7:

Commons Collections

COLLECTIONS-732

Got an UnsupportedOperationException when using MultiValuedMap.MapIterator().setValue()

Bug

Open

Major

Unresolved

Unassigned

Chen

05/Nov/19 12:36

18/Mar/20 02:46

18/Jan/20 08:47

Map

0

2

copy from https://issues.apache.org/jira/browse/COLLECTIONS-663
{code:java}
public void testSetValueMapIterator(){
final ListValuedMap<String, String> listMap = new ArrayListValuedHashMap<>();
List<String> listA = listMap.get("A");
listA.addAll(0, Arrays.asList("W", "X", "F"));
List<String> listB = listMap.get("B");
listB.addAll(0, Arrays.asList("Q", "Q", "L"));
assertEquals("{A=[W, X, F], B=[Q, Q, L]}", listMap.toString());

for(MapIterator<String, String> iterator = listMap.mapIterator(); iterator.hasNext(); ){
iterator.next();
String value = iterator.getValue();
if(value == "F"){
iterator.setValue("B");
}
}
assertEquals("{A=[W, X, B], B=[Q, Q, L]}", listMap.toString());
}
{code}
It throws an UnsupportedOperationException when altering mapIterator().setValue()。
I found UnsupportedOperationException is thrown in the code of setValue。So，if setValue method is not supported，the Javadoc should comment it。

12/Jan/20 12:28 AM

8 weeks, 3 days ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|z089tk:

Commons Collections

COLLECTIONS-445

Several unit test failures with IBM JDK 6

Bug

Closed

Blocker

Fixed

Unassigned

Thomas Neidhart

26/Feb/13 21:21

09/Nov/14 14:31

21/Apr/13 17:48

4.0-alpha1, 4.0

0

Failed tests:
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value] expected:<1> but was:<0>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value, value, seev, tmpv, we'llv, youv] expected:<6> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractMapTest$TestMapKeySet>AbstractCollectionTest.testCollectionRemove:881 Collection should remove extant element: key
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<again>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<again>
AbstractBidiMapTest$TestInverseBidiMap>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<again>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv>
DualTreeBidiMapTest>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<againv>
AbstractOrderedBidiMapTest$TestBidiOrderedMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<againv>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value] expected:<1> but was:<0>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [value, value2, seev, tmpv, we'llv, youv] expected:<6> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: againv
Test: []
Real: []
AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv>
AbstractIterableMapTest$InnerTestMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<you>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<you>
AbstractBidiMapTest$TestInverseBidiMap>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<you>
AbstractBidiMapTest$TestBidiMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv>
DualTreeBidiMap2Test>AbstractBidiMapTest.testBidiMapIteratorSet:560 expected same:<For> was not:<youv>
AbstractOrderedBidiMapTest$TestBidiOrderedMapIterator>AbstractMapIteratorTest.testMapIteratorSet:214 Value must be changed after setValue expected same:<newnonnullvalue> was not:<youv>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [foov] expected:<1> but was:<0>
AbstractSortedMapTest$TestTailMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2010 values should be same size as HashMap's
Test: []
Real: [againv, allv, barv, bazv, blahv, foov] expected:<6> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionClear:638->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRemoveAll:930->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv
Test: []
Real: []
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionRetainAll:973->verify:1888->AbstractCollectionTest.verify:294 Collection should not contain a value that the confirmed collection does not have: youv
Test: []
Real: []
AbstractMapTest$TestMapEntrySet>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>
AbstractMapTest$TestMapValues>AbstractCollectionTest.testCollectionIteratorRemove:838 Collection should shrink by one after iterator.remove expected:<-1> but was:<0>

Tests in error:
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPut:808->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer
AbstractSortedMapTest$TestHeadMap>AbstractMapTest.testMapPutAll:952->AbstractSortedMapTest$TestViewMap.verify:141->AbstractMapTest.verify:1946->AbstractMapTest.verifyValues:2006 » NullPointer

6 years, 48 weeks, 2 days ago

314784

No Perforce job exists for this issue.

1

315128

0|i1ibjb:

Commons Collections

COLLECTIONS-408

performance problem in SetUniqueList.removeAll()

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

02/Jun/12 06:56

09/Nov/14 14:31

19/Jun/12 19:22

4.0-alpha1, 4.0

0

2

COLLECTIONS-407

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in SetUniqueList.removeAll().
It appears in version 3.2.1 and also in revision 1344775 (31 May
2012). I have attached a test that exposes this problem and a
one-line patch that fixes it. The patch makes the code two times
faster for this test.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is: 5027

The output for the patched version is:
Time is: 2554

The one-line patch I attached changes the
SetUniqueList.removeAll(Collection<?> coll) code from:

boolean result = super.removeAll(coll);
set.removeAll(coll);
return result;

to:

boolean result = super.removeAll(coll);
if (result) set.removeAll(coll);
return result;

If "super.removeAll(coll)" did not change the collection, there is no
need to call "set.removeAll(coll)", because we already know there is
nothing to remove.

As one may expect "set.removeAll(coll)" (on a set) to be faster than
"super.removeAll(coll)" (on a list), one may have expected the speedup
gained by avoiding "set.removeAll(coll)" to be smaller than 2X
achieved for the attached test. However, the speedup is 2X because
"java.util.HashSet.removeAll(Collection<?> collection)" has quadratic
(not linear) complexity if "this.size() <= collection.size()" and the
"collection" is a list. Thus, "set.removeAll(coll)" is about as slow
as "super.removeAll(coll)" in this case, and not executing
"set.removeAll(coll)" reduces the work done by half. The quadratic
behavior of "java.util.HashSet.removeAll(Collection<?> collection)"
comes from "java.util.AbstractSet.removeAll(Collection<?> c)" and is
discussed for example here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007148.html
(The link is for OpenJDK, but Oracle JDK has the same problem.)

In many other cases "set.removeAll(coll)" is actually faster than
"super.removeAll(coll)", so one can get even more speedup by
reordering those two checks:

boolean result = set.removeAll(coll);
if (result) super.removeAll(coll);
return result;

Is this a bug, or am I misunderstanding the intended behavior? If so,
can you please confirm that the patch is correct?

Thanks,

Adrian

19/Jun/12 7:22 PM

7 years, 40 weeks ago

292950

No Perforce job exists for this issue.

2

164352

0|i0shqv:

Commons Collections

COLLECTIONS-473

AbstractCollectionDecorator.decorated() should not be used internally

Bug

Closed

Major

Fixed

Unassigned

Sebb

17/Jun/13 22:17

09/Nov/14 14:31

18/Jun/13 20:29

4.0-alpha1, 4.0

0

AbstractCollectionDecorator.decorated() is used internally to access the collection.
However, the method is not final, so subclasses could override it.

Yet the field is also exposed (protected).

This is inconsistent.

Is there any use-case for overriding the collection to use a different one?
If so, having direct access as well is likely to cause problems.

I think it would be better to use the field directly internally.
The class Javadoc says the calls are forwarded to the underlying collection, but that is not strictly true if decorated() is overridden.

If it is intended to allow this to be overridden, then the field needs to be protected against arbitrary read/write access.

The field should probably be made private with a setter for use by deserialization only.

18/Jun/13 8:28 AM

6 years, 40 weeks ago

333609

No Perforce job exists for this issue.

0

333937

0|i1ljsn:

Commons Collections

COLLECTIONS-468

Change Bag interface and implementations to conform to Collection interface

Bug

Closed

Major

Fixed

Unassigned

Thomas Neidhart

13/May/13 20:57

09/Nov/14 14:31

17/Jun/13 21:06

4.0-alpha1, 4.0

0

1

Several methods of the Bag interface do not conform to the Collection interface (e.g. add, remove, containsAll, removeAll, retainAll).
This should be fixed for 4.0.

13/May/13 10:39 PM

6 years, 37 weeks, 4 days ago

327730

No Perforce job exists for this issue.

3

328074

0|i1kjnz:

Commons Collections

COLLECTIONS-461

splitmap.TransformedMap is not really a Map

Bug

Closed

Major

Fixed

Unassigned

Sebb

06/May/13 10:16

09/Nov/14 14:31

14/May/13 20:02

4.0-alpha1, 4.0

0

1

splitmap.TransformedMap is part of the Get/Put hierarchy, but it does not behave like a proper Java Map.

In particular, java.util.Map.put(K, V) returns V.
However the collections Put interface returns Object.
As far as I can tell, this was done in order to be able to include TransformedMap in the hiearchy. But the side effect is to break the generics for all the non-transformer maps in the hierarchy.

Maybe there should be a separate PutTransformed interface which has the appropriate generic types, i.e.

public T put(K key, V value)

13/May/13 10:39 PM

6 years, 45 weeks ago

326546

No Perforce job exists for this issue.

0

326891

0|i1kc3b:

Commons Collections

COLLECTIONS-458

AbstractUntypedCollectionDecorator<E, D> is not used

Bug

Closed

Major

Fixed

Unassigned

Sebb

29/Apr/13 22:20

27/Nov/15 21:11

30/Apr/13 12:00

0

The public ctor for AbstractUntypedCollectionDecorator<E, D> takes no argument and so collection = null; however the protected ctor checks for collection parameter != null.

The decorated() method says that all access to collection goes through it, and there is no setter.

At present the only way to recover from calling the public ctor is for the sub-class to set collection directly.

This is inconsistent.

The class is abstract and there appear to be no concrete subclasses. Looks like the class might be superfluous, but if it is required, it should ideally have a private final collection field.

30/Apr/13 5:24 AM

6 years, 47 weeks ago

325684

No Perforce job exists for this issue.

0

326029

0|i1k6rz:

Commons Collections

COLLECTIONS-459

ArrayIterator & ObjectArrayIterator - do they need setters?`

Bug

Closed

Major

Fixed

Unassigned

Sebb

30/Apr/13 12:15

09/Nov/14 14:31

18/Jun/13 19:35

4.0-alpha1, 4.0

0

ArrayIterator & ObjectArrayIterator both have methods to set the array separately from the ctor.

However the method does not allow the same flexibility as the ctor, as it does not allow the start or end indexes to be set.

Is there really a use-case for these setters? If not, all the fields apart from index could be made final, which would make thread safety (and testing) easier.

30/Apr/13 1:43 PM

6 years, 40 weeks ago

325781

No Perforce job exists for this issue.

0

326126

0|i1k7dj:

Commons Collections

COLLECTIONS-455

AbstractDualBidiMap<K, V> has several mutable protected fields

Bug

Closed

Major

Fixed

Unassigned

Sebb

29/Apr/13 00:05

09/Nov/14 14:31

18/Jun/13 20:55

4.0-alpha1, 4.0

0

Any non-private mutable fields make it much harder to ensure thread-safety as well as making it very difficult to test thoroughly.

The fields should be made private.
If protected write access really is needed, setter methods should be used.
These methods can take any necessary precautions to ensure thread-safety.

05/May/13 4:21 PM

6 years, 40 weeks ago

325480

No Perforce job exists for this issue.

0

325825

0|i1k5in:

Commons Collections

COLLECTIONS-588

Redundant computation in CollectionBag and CollectionSortedBag

Bug

Open

Major

Unresolved

Unassigned

Monika Dhok

02/May/16 16:18

12/Jan/20 00:47

0

2

There appears to be redundant computations in "CollectionBag.retainAll"
method in the version 4.4.1. I have attached a test and proposed a small
patch which ensures that "contains" method is called on hashset of
input collection. This patch gives 892X speed up on my
machine for the provided test.
Similar patches can be applied for, "CollectionSortedBag.retainAll".

12/Jan/20 12:46 AM

9 weeks, 3 days ago

9223372036854775807

No Perforce job exists for this issue.

2

9223372036854775807

Patch

0|i2x1pz:

Commons Collections

COLLECTIONS-583

JAVA serialization vulnerability "CVE-2015-4852" in commons-collections*.jar

Bug

Resolved

Major

Duplicate

Unassigned

Arnoj Saha

14/Dec/15 07:02

14/Dec/15 07:47

3.2.2, 4.1

0

2

COLLECTIONS-580

The vulnerability we are talking about is known under number CVE-2015-4852. As far as we know this is only related to the

file commons-collections*.jar. In this jar file is a class that takes care of the deserialization.

Currently we are using commons-collections-3.2.1.jar.
Is there a version of this jar that does not have this vulnerability?

4 years, 14 weeks, 1 day ago

9223372036854775807

No Perforce job exists for this issue.

0

9223372036854775807

0|i2pucf:

Commons Collections

COLLECTIONS-438

ExtendedProperties : String only composed of spaces character

Bug

Closed

Major

Invalid

Unassigned

Guillaume Chauvet

28/Dec/12 09:00

27/Nov/15 21:47

22/Jan/13 13:56

Collection

0

1

We have discovered a bug in ExtendedProperties class used in our internal language manager framework. The cause are strings which contains only spaces character. We provide a patch to complete the JUnit class ExtendedPropertiesTest.

20/Jan/13 11:57 AM

7 years, 9 weeks, 2 days ago

301949

No Perforce job exists for this issue.

1

248577

0|i16xlr:

Commons Collections

COLLECTIONS-437

CollectionUtils.removeAll invoke ListUtils.retainAll !!!

Bug

Closed

Critical

Duplicate

Unassigned

qxo

26/Dec/12 07:04

09/Nov/14 14:31

28/Feb/13 18:38

4.0-alpha1, 4.0

0

2

COLLECTIONS-219

public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove);
}

29/Dec/12 3:08 PM

7 years, 12 weeks, 3 days ago

301779

No Perforce job exists for this issue.

0

248392

0|i16wgv:

Commons Collections

COLLECTIONS-449

Latest Version is set to 20040616

Bug

Closed

Critical

Won't Fix

Joerg Schaible

Kai Cabuslay

14/Mar/13 02:50

14/Mar/13 07:28

0

2

The current maven metadata file for commons-collections shows that the "latest version" is 20040616. This is currently affecting spring-webmvc (3.1.3-RELEASE) - causing it to use the outdated version of the collections package.

http://repo1.maven.org/maven2/commons-collections/commons-collections/maven-metadata.xml

14/Mar/13 7:28 AM

7 years, 1 week, 5 days ago

317440

No Perforce job exists for this issue.

0

317781

0|i1irwf:

Commons Collections

COLLECTIONS-421

Update JavaDoc in ListUtils to discribe generified methods

Bug

Closed

Trivial

Fixed

Unassigned

Benedikt Ritter

07/Jul/12 14:47

09/Nov/14 14:31

14/Jul/12 21:36

4.0-alpha1, 4.0

Collection

0

2

The JavaDoc of {{ListUtils.lazyList()}} and {{ListUtils.fixedSizeList}} still refer to the old methods prior to generics. This should be updated.

14/Jul/12 9:36 PM

7 years, 36 weeks, 2 days ago

292942

No Perforce job exists for this issue.

1

164344

0|i0shp3:

Commons Collections

COLLECTIONS-412

CollectionUtils.subtract() is very slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

20/Jun/12 20:44

09/Nov/14 14:31

23/Jun/12 11:34

4.0-alpha1, 4.0

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in CollectionUtils.subtract().
It appears in version 3.2.1 and also in revision 1352300 (20 June
2012). I attached a test that exposes this problem and a patch that
fixes it. On my machine, for this test, the patch provides a 204X
speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 11036

The output for the patched version is:
Time is 54

The root cause of this problem is similar to the root cause of the
previously fixed COLLECTIONS-406 in ListUtils.subtract(), i.e.,
quadratic complexity instead of linear complexity. This problem
affects two methods:

CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b)
and
CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b, final Predicate<O> p)

because the former just calls the latter.

Currently, the code for
"CollectionUtils.subtract(final Iterable<? extends O> a, final Iterable<? extends O> b, final Predicate<O> p)"
is:

ArrayList<O> list = new ArrayList<O>();
addAll(list, a);
for (O element : b) {
if (p.evaluate(element)) {
list.remove(element);
}
}

which is quadratic, because "list.remove(element)" has linear
complexity for "ArrayList<O> list = new ArrayList<O>()".

The attached patch makes the remove() be constant complexity by
removing from an org.apache.commons.collections.bag.HashBag. The
attached patch is very similar to the patch of COLLECTIONS-406, so I
assume the risk of applying this patch is minimal. Just like in the
patch for COLLECTIONS-406, this patch uses a HashBag (and not a
HashSet) to respect cardinality when there are repeated objects.

Can you please confirm if the patch is correct?

Thanks,

Adrian

23/Jun/12 11:34 AM

7 years, 39 weeks, 3 days ago

292946

No Perforce job exists for this issue.

2

164348

0|i0shpz:

Commons Collections

COLLECTIONS-411

Exception in ListOrderedMap.putAll()

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

20/Jun/12 15:45

09/Nov/14 14:31

20/Jun/12 17:54

4.0-alpha1, 4.0

0

2

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering an IndexOutOfBoundsException in
ListOrderedMap.putAll(int index, Map<? extends K, ? extends V> map).
It appears in revision 1351903 (20 June 2012). I have attached a test
that exposes this problem.

To run the test, just do:

$ java Test

The output is:

......................................................................
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 5, Size: 4
at java.util.ArrayList.add(ArrayList.java:367)
at org.apache.commons.collections.map.ListOrderedMap.put(ListOrderedMap.java:437)
at org.apache.commons.collections.map.ListOrderedMap.putAll(ListOrderedMap.java:245)
at Test.main(Test.java:19)
......................................................................

The documentation does not specify anything like this. Is this a bug,
or should the documentation just be updated? If the former, is there
a patch for it?

Thanks,

Adrian

20/Jun/12 5:54 PM

7 years, 39 weeks, 6 days ago

292947

No Perforce job exists for this issue.

1

164349

0|i0shq7:

Commons Collections

COLLECTIONS-410

SetUniqueList.addAll() is very slow

Bug

Closed

Major

Fixed

Unassigned

Adrian Nistor

19/Jun/12 20:37

09/Nov/14 14:31

20/Jun/12 18:04

4.0-alpha1, 4.0

0

3

java 1.6.0_24
Ubuntu 11.10

Hi,

I am encountering a performance problem in SetUniqueList.addAll(). It
appears in revision 1351837 (19 June 2012). I attached a test that
exposes this problem and a patch that fixes it. On my machine, for
this test, the patch provides a 540X speedup.

To run the test, just do:

$ java Test

The output for the un-patched version is:
Time is 2706

The output for the patched version is:
Time is 5

As the patch shows, the problem is that
SetUniqueList.addAll(int index, Collection<? extends E> coll)
performs:
"add(index, e)" for each element in "coll". This is very expensive,
because each "add(index, e)" performs a
LinkedList.add(int index, E element), which requires traversing the
LinkedList to find the index.

The patched version avoids this cost by inserting all the elements at
once, thus performing only one insert.

Is this a bug? If so, can you please confirm that the patch is
correct?

Thanks,

Adrian

20/Jun/12 6:04 PM

7 years, 39 weeks, 6 days ago

292948

No Perforce job exists for this issue.

2

164350

0|i0shqf:

Commons Collections

COLLECTIONS-527

Please create a version commons-collections 3.x for jdk 8 compatibility

Bug

Closed

Blocker

Won't Fix

Unassigned

Ignat Alexeyenko

15/May/14 10:12

27/Nov/15 21:47

16/May/14 23:00

0

3

Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for these, who implement common's MultiMap.

*Compilation Error*
If anyone implement MultiMap in their code, compilation fails with the error:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with Java 8. For many big project switch to commons-collections 4.x is not an option - some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their internal artifact. Why do it if the official compatibility version can be created?

Thanks!

java8, jdk8

16/May/14 3:15 PM

5 years, 44 weeks, 4 days ago

392748

No Perforce job exists for this issue.

1

392924

0|i1vmtr:

Commons Collections

COLLECTIONS-521

Typo in MultiMapKey's isEqualKey(entry, key1, key2)

Bug

Closed

Major

Fixed

Unassigned

Maxime Nay

01/May/14 20:51

27/Nov/15 21:11

06/May/14 21:38

4.1

0

2

I believe there is a typo line 252 in MultiKeyMap.
return
multi.size() == 2 &&
(key1 == multi.getKey(0) || key1 != null && key1.equals(multi.getKey(0))) &&
(key2 == multi.getKey(1) || key1 != null && key2.equals(multi.getKey(1)));

should be:
return
multi.size() == 2 &&
(key1 == multi.getKey(0) || key1 != null && key1.equals(multi.getKey(0))) &&
(key2 == multi.getKey(1) || key2 != null && key2.equals(multi.getKey(1)));

01/May/14 9:01 PM

5 years, 44 weeks, 2 days ago

390113

No Perforce job exists for this issue.

0

390350

0|i1v71r:

Commons Collections

COLLECTIONS-332

ListOrderedMap not respecting underlying list

Bug

Closed

Minor

Fixed

Unassigned

Tom Parker

10/Jul/09 02:24

09/Nov/14 14:31

08/Mar/11 21:34

4.0-alpha1, 4.0

Map

0

1

When decorating either CaseInsensitiveMap or IdentityMap (and I believe this will impact any java.util.TreeMap built with a non-.equals() Comparator), ListOrderedMap responds inconsistently with the underlying map. The ordering seems to be operating off .equals() rather than the actual contents of the underlying map.

26/Jul/09 8:13 PM

9 years, 3 weeks ago

18671

No Perforce job exists for this issue.

1

164409

0|i0si3j:

Commons Collections

COLLECTIONS-330

ConcurrentModificationException using remove from the keySet the LRUMap

Bug

Closed

Major

Fixed

Unassigned

Joerg Schaible

17/Jun/09 09:52

09/Nov/14 14:31

21/Feb/11 19:17

4.0-alpha1, 4.0

Collection

0

COLLECTIONS-3

Even if the access to a LRUMap is synced and the remove method of the iterator is used that has been returned from the keySet of the LRUMap, it is possible to get a ConcurrentModificationException. This does not happen for remove of the iterators returned by the entrySet or values of the LRUMap. See currently not executed unit test in TestLRUMap (marked as TODO for COLLECTION-3).

17/Jun/09 11:07 PM

9 years, 5 weeks, 1 day ago

18673

No Perforce job exists for this issue.

0

164411

0|i0si3z:

Commons Collections

COLLECTIONS-380

UnmodifiableBoundedCollection.unmodifiableBoundedCollection is an infinite loop

Bug

Closed

Minor

Fixed

Unassigned

Dave Brosius

29/Sep/11 18:45

09/Nov/14 14:31

09/Apr/12 18:41

4.0-alpha1, 4.0

Collection

0

This method, just calls itself. As BoundedCollection extends Collection, it would seem to me that this method should be removed:

/**
* Factory method to create an unmodifiable bounded collection.
*
* @param coll the <code>BoundedCollection</code> to decorate, must not be null
* @return a new unmodifiable bounded collection
* @throws IllegalArgumentException if bag is null
*/
public static <E> BoundedCollection<E> unmodifiableBoundedCollection(BoundedCollection<E> coll) {
return unmodifiableBoundedCollection(coll);
}

02/Jan/12 6:07 PM

7 years, 50 weeks, 1 day ago

40352

No Perforce job exists for this issue.

0

164374

0|i0shvr:

Commons Collections

COLLECTIONS-364

DualTreeBidiMap.readObject() uses wrong comparator to create reverseMap

Bug

Closed

Major

Fixed

Sebb

18/Oct/10 18:51

27/Nov/15 21:11

18/Oct/10 19:17

BidiMap

0

DualTreeBidiMap.readObject() uses the wrong comparator to create reverseMap. The code reads:

bq. reverseMap = new TreeMap(comparator);

it should read:

bq. reverseMap = new TreeMap(valueComparator);

Note: this was found when trying to fix generics warnings.

9 years, 23 weeks, 1 day ago

18639

No Perforce job exists for this issue.

0

164384

0|i0shxz:

Commons Collections

COLLECTIONS-378

Incorrect links in JavaDoc

Bug

Closed

Major

Implemented

Unassigned

Ken Dombeck

08/Aug/11 16:54

09/Nov/14 14:31

28/Feb/13 19:17

4.0-alpha1, 4.0

0

COLLECTIONS-251

The links for several JavaDocs were not updated during the implementation of COLLECTIONS-251.

Attached patch file includes the necessary changes.

09/Apr/12 6:09 PM

7 years, 50 weeks, 1 day ago

18625

No Perforce job exists for this issue.

1

164376

0|i0shw7:

Commons Collections

COLLECTIONS-340

NOPClosure has a broken equals method

Bug

Closed

Minor

Fixed

Unassigned

Goran Hacek

14/Oct/09 11:45

09/Nov/14 14:31

28/Feb/13 19:55

4.0-alpha1, 4.0

Functor

0

Equals method of NOPClosure class doesn't follow objects equals contract. It isn't symmetric nor transitive and it is just plain wrong.

Following code evaluates to true on most (if not all) JVM implementations:
{noformat} NOPClosure.INSTANCE.equals(new Integer(System.identityHashCode(NOPClosure.INSTANCE))) {noformat}

14/Oct/09 2:18 PM

6 years, 48 weeks ago

18663

No Perforce job exists for this issue.

0

164402

0|i0si1z:

Commons Collections

COLLECTIONS-334

map.StaticBucketMap.size() needs to synchronize access to lock

Bug

Closed

Major

Fixed

Jochen Wiedmann

Sebb

11/Sep/09 17:46

08/Nov/15 21:07

01/Mar/11 22:36

3.2.2, 4.0-alpha1, 4.0

Collection

0

collections_jdk5_branch

The field Lock.size is updated using synchronization, however the StaticBucketMap.size() method reads the values without synch.

If the read is done in a different thread from the updates, there is no guarantee that the reading thread will see the most recent value.

01/Mar/11 10:36 PM

9 years, 4 weeks ago

18669

No Perforce job exists for this issue.

0

164408

0|i0si3b:

Commons Collections

COLLECTIONS-343

Functor singleton classes do not implement singleton pattern correctly

Bug

Closed

Major

Fixed

Unassigned

Goran Hacek

15/Oct/09 12:15

09/Nov/14 14:31

28/Feb/13 19:37

4.0-alpha1, 4.0

Functor

0

All classes in package "org.apache.commons.collections.functors" that advertise that they have singleton instance actually cannot guarantee that. Because of serialization support multiple instances of those classes can exist at runtime.

Following classes are making this false claim:
* CloneTransformer
* ExceptionClosure
* ExceptionFactory
* ExceptionPredicate
* ExceptionTransformer
* FalsePredicate
* NOPClosure
* NOPTransformer
* NotNullPredicate
* NullPredicate
* StringValueTransformer
* TruePredicate

29/Dec/09 11:12 PM

10 years, 13 weeks ago

18660

No Perforce job exists for this issue.

1

164400

0|i0si1j:

Commons Collections

COLLECTIONS-335

bidimap.TreeBidiMap.entrySet is never written

Bug

Closed

Major

Fixed

Jochen Wiedmann

Sebb

11/Sep/09 22:17

07/Nov/15 20:31

01/Mar/11 22:28

3.2.2, 4.0-alpha1, 4.0

0

The field bidimap.TreeBidiMap.entrySet is never written.

Looks like it was perhaps intended to be used as a cache, but the cache value is not written.

02/Feb/10 12:14 AM

9 years, 4 weeks ago

18668

No Perforce job exists for this issue.

0

164407

0|i0si33:

Commons Collections

COLLECTIONS-337

BasicPredicateTestBase.assertFalse & BasicPredicateTestBase.assertTrue methods have confusing names

Bug

Closed

Major

Won't Fix

Unassigned

Sebb

15/Sep/09 19:32

19/Jun/10 19:43

0

BasicPredicateTestBase.assertFalse & BasicPredicateTestBase.assertTrue methods have confusing names - they are the same as the JUnit names, but don't override them.

Of course it's still possible to use the JUnit versions of the methods, but the code is harder to understand.

19/Jun/10 7:43 PM

9 years, 40 weeks, 3 days ago

18666

No Perforce job exists for this issue.

0

164405

0|i0si2n:

Commons Collections

COLLECTIONS-299

ExtendedProperties.convertProperties loses non-String values

Bug

Closed

Major

Fixed

Unassigned

Simon Kitching

16/Jun/08 11:13

27/Nov/15 21:11

28/Feb/13 19:37

Core

0

COLLECTIONS-351

A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.

ExtendedProperties.convertProperties does this:
{code}
for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
String s = (String) e.nextElement();
c.setProperty(s, props.getProperty(s));
}
{code}

Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.

It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.

Perhaps the call
props.getProperty(s)
can be changed to
props.get(s)

Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.

16/Jun/08 11:46 AM

6 years, 48 weeks ago

18702

No Perforce job exists for this issue.

0

164434

0|i0si93:

Commons Collections

COLLECTIONS-321

ComparableComparator.getInstance() not compilable with jdk-compiler

Bug

Closed

Major

Fixed

Unassigned

Daniel Golesny

24/Feb/09 11:10

09/Nov/14 14:31

28/Feb/13 20:24

4.0-alpha1, 4.0

Comparator

0

1

Comparator<Integer> c = ComparableComparator.getInstance();

This line is valid with eclipse (3.4) compiler, but the jdk 1.5.0 compiler returns this error:
[javac] J:\workspace\ndt\cobolclipse-TRUNK\collections_jdk5_branch\src\java\org\apache\commons\collections\comparators\ComparableComparatorTest.java:23: incompatible types; no instance(s) of type variable(s) E exist so that org.apache.commons.collections.comparators.ComparableComparator<E> conforms to java.util.Comparator<java.lang.Integer>
[javac] found : <E>org.apache.commons.collections.comparators.ComparableComparator<E>
[javac] required: java.util.Comparator<java.lang.Integer>
[javac] Comparator<Integer> c = ComparableComparator.getInstance();
[javac] ^
[javac] 1 error

11/Sep/09 4:14 PM

10 years, 28 weeks, 4 days ago

18680

No Perforce job exists for this issue.

0

164416

0|i0si53:

Commons Collections

COLLECTIONS-320

StaticBucketMap#putall() uses inefficient keySet() iterator when it could use entrySet() iterator

Bug

Closed

Minor

Fixed

Unassigned

Sebb

16/Feb/09 21:58

09/Nov/14 14:31

28/Feb/13 19:58

4.0-alpha1, 4.0

Map

0

StaticBucketMap#putall() uses inefficient keySet() iterator when it could use entrySet() iterator.

Patch to follow.

23/Apr/09 2:45 AM

10 years, 48 weeks, 6 days ago

18681

No Perforce job exists for this issue.

1

164417

0|i0si5b:

Commons Collections

COLLECTIONS-319

IteratorUtils.getIterator(Object obj) performs redundant null check

Bug

Closed

Minor

Fixed

Unassigned

Sebb

16/Feb/09 19:35

09/Nov/14 14:31

28/Feb/13 20:24

4.0-alpha1, 4.0

Collection

0

IteratorUtils.getIterator(Object obj) performs redundant null check:

{code}
if (obj == null) {
return emptyIterator();
...
} else if (obj != null && obj.getClass().isArray()) {
return new ArrayIterator(obj);
{code}

obj cannot be null at that point, so the check can be removed.
[This will also prevent a false positive in Eclipse which later says tha obj may be null]

23/Apr/09 2:37 AM

10 years, 48 weeks, 6 days ago

18682

No Perforce job exists for this issue.

0

164418

0|i0si5j:

Commons Collections

COLLECTIONS-318

CollectionUtils.size(Object object) has impossible null check

Bug

Closed

Minor

Fixed

Unassigned

Sebb

16/Feb/09 19:28

09/Nov/14 14:31

28/Feb/13 19:58

4.0-alpha1, 4.0

Collection

0

CollectionUtils.size(Object object) has impossible null check:

{code}
public static int size(Object object) {
if (object == null) {
return 0;
}
...
} else if (object == null) {
throw new IllegalArgumentException("Unsupported object type: null");
...
{code}

The Javadoc specifically says that null is allowed, so I think the object == null clause needs to be removed - it can never be true, and is just confusing.

23/Apr/09 2:39 AM

10 years, 48 weeks, 6 days ago

18683

No Perforce job exists for this issue.

0

164419

0|i0si5r:

Commons Collections

COLLECTIONS-317

AbstractHashedMap(Map map) constructor calls overridable non-final method

Bug

Closed

Minor

Fixed

Unassigned

Sebb

16/Feb/09 16:18

09/Nov/14 14:31

28/Feb/13 20:04

4.0-alpha1, 4.0

Map

0

The constructor AbstractHashedMap(Map map) calls the public non-final method putAll() from the same class.

This is likely to cause problems if the method is ever overridden, as the parent may not have been completely initialised when the sub-class method is invoked.

Possible solution: extract the code into a common private method. Or make the method final.

16/Feb/09 4:47 PM

10 years, 44 weeks, 6 days ago

18684

No Perforce job exists for this issue.

0

164420

0|i0si5z:

Commons Collections

COLLECTIONS-288

Javadoc: incorrect behavior explained for ListUtils.transformedList

Bug

Closed

Major

Fixed

Unassigned

Paul Benedict

17/Mar/08 16:34

09/Nov/14 14:31

28/Feb/13 19:38

4.0-alpha1, 4.0

List

0

COLLECTIONS-256, COLLECTIONS-348

The contract stated for ListUtils.transformedList is wrong. The list is not transformed -- it decorates the existing list and transforms NEW objects -- EXISTING objects are not transformed.

Compare this to the javadoc found in MapUtils.transformedMap:
"This method returns a new map (decorating the specified map) that will transform any new entries added to it. Existing entries in the specified map will not be transformed. "

That little missing piece of information messed me up. Just replace "map" with "list" and append it to the existing LilstUtils javadoc.

18/Mar/08 6:10 AM

12 years, 2 weeks ago

18712

No Perforce job exists for this issue.

0

164442

0|i0siav:

Commons Collections

COLLECTIONS-45

[collections] ReferenceMap size of bug.

Bug

Closed

Critical

Cannot Reproduce

Unassigned

emily

16/Feb/06 04:26

15/Mar/08 21:35

0

Operating System: other
Platform: PC

I have the following declaration of my map:

Here is the code:
System.err.println("elements are " + elements + "\n\t element size is " +
elements.size() + "\n\tkey set " + elements.keySet() + "\n\telements:" +
elements.values());
Iterator iter = elements.keySet().iterator();
while (iter.hasNext()) {
Object element = iter.next();
System.err.println("next element:" + element);
}
System.err.println("--------------");
Here is the results below, where usually the answer is 2 but occationally 3

elements are {Concept=ConceptImpl Concept, ValueSet=ConceptImpl ValueSet}
element size is 3
key set [Concept, ValueSet]
elements:[ConceptImpl Concept, ConceptImpl ValueSet]
next element:Concept
next element:ValueSet
--------------
size:3

16/Feb/06 4:36 AM

14 years, 4 weeks, 4 days ago

18953

No Perforce job exists for this issue.

0

38661

164663

0|i0sjnz:

Commons Collections

COLLECTIONS-13

[collections] Typo in user documentation

Bug

Closed

Trivial

Fixed

Unassigned

Chad McHenry

17/Jan/05 07:34

15/Mar/08 21:35

0

Operating System: All
Platform: All

Will attach patch momentarily.

04/Feb/05 9:22 AM

15 years, 8 weeks, 4 days ago

18985

No Perforce job exists for this issue.

1

33125

164695

0|i0sjv3:

Commons Collections

COLLECTIONS-7

[collections] BlockingBuffer waits/notifies wrong Object?

Bug

Closed

Major

Fixed

Unassigned

Sebb

12/Oct/05 04:22

15/Mar/08 21:35

0

Operating System: other
Platform: Other

The code contains various examples of the form:

synchronized (lock) {
...
notifyAll();
}

which should probably be:

synchronized (lock) {
...
lock.notifyAll();
}

Patch to follow

12/Oct/05 6:11 AM

14 years, 24 weeks, 3 days ago

18991

No Perforce job exists for this issue.

1

37028

164701

0|i0sjwf:

Commons Collections

COLLECTIONS-121

[Collections] Improvements to maven build

Bug

Closed

Major

Fixed

Unassigned

Carlos Sanchez Gonzalez

11/Oct/05 08:07

15/Mar/08 21:36

0

Operating System: other
Platform: Other

Improvements to project.xml updating deprecated tags and making it easier for
maven 2 users.

14 years, 25 weeks ago

18877

No Perforce job exists for this issue.

1

37012

164587

0|i0sj73:

Commons Collections

COLLECTIONS-43

[collections] serialVersionUID should be private

Bug

Closed

Minor

Fixed

Unassigned

Sebb

17/Oct/05 04:03

15/Mar/08 21:35

0

Operating System: other
Platform: Other

The following classes define serialVersionUID with default (package) access:

HashBag
TreeBag
functors.*
NodeCachingLinkedList
LRUMap

This field should be defined as private.

04/Nov/05 8:07 AM

14 years, 18 weeks, 6 days ago

18955

No Perforce job exists for this issue.

0

37106

164665

0|i0sjof:

Commons Collections

COLLECTIONS-127

[collections] Strong reference not really cleared in TestReference*Map testcases

Bug

Closed

Major

Fixed

Unassigned

Guilhem Lavaux

01/May/05 02:21

15/Mar/08 21:36

0

Operating System: All
Platform: All

It seems TestReference*Map fail to remove completely the strong references in
testPurgeValues because some optimization may be done for local variables by a
JIT compiler. It may be seen with CVS head of the kaffe VM. I suggest to modify
the testcases using the attached patch. It makes sure that no optimized local
variables are still on the stack. The bug is present in the head of SVN tree
(2005-04-30). It is fully reproduceable on kaffe VM (2005-04-30) with JIT3/x86.

08/May/05 2:28 AM

14 years, 47 weeks, 3 days ago

18871

No Perforce job exists for this issue.

1

34689

164581

0|i0sj5r:

Commons Collections

COLLECTIONS-129

[collections] Flat3Map.equals() bug

Bug

Closed

Major

Fixed

Unassigned

Stanislaw Osinski

15/May/05 01:27

15/Mar/08 21:36

0

Operating System: Windows XP
Platform: PC

Flat3Map.equals() fails a simple test:

public void testEquals()
{
Flat3Map map = new Flat3Map();
map.put("a", "testA");
map.put("b", "testB");
Flat3Map mapClone = new Flat3Map();
mapClone.put("a", "testB");
mapClone.put("b", "testA");

assertFalse("Maps should not be equal", map.equals(mapClone));
}

The code of Flat3Map.equals() is:

public boolean equals(Object obj) {
if (obj == this) {
return true;
}
if (delegateMap != null) {
return delegateMap.equals(obj);
}
if (obj instanceof Map == false) {
return false;
}
Map other = (Map) obj;
if (size != other.size()) {
return false;
}
if (size > 0) {
Object otherValue = null;
switch (size) { // drop through
case 3:
if (other.containsKey(key3) == false) {
otherValue = other.get(key3);
if (value3 == null ? otherValue != null :
!value3.equals(otherValue)) {
return false;
}
}
case 2:
if (other.containsKey(key2) == false) {
otherValue = other.get(key2);
if (value2 == null ? otherValue != null :
!value2.equals(otherValue)) {
return false;
}
}
case 1:
if (other.containsKey(key1) == false) {
otherValue = other.get(key1);
if (value1 == null ? otherValue != null :
!value1.equals(otherValue)) {
return false;
}
}
}
}
return true;
}

while it should probably be:

public boolean equals(Object obj) {
if (obj == this) {
return true;
}
if (delegateMap != null) {
return delegateMap.equals(obj);
}
if (obj instanceof Map == false) {
return false;
}
Map other = (Map) obj;
if (size != other.size()) {
return false;
}
if (size > 0) {
Object otherValue = null;
switch (size) { // drop through
case 3:
if (other.containsKey(key3)) {
otherValue = other.get(key3);
if (value3 == null ? otherValue != null :
!value3.equals(otherValue)) {
return false;
}
}
case 2:
if (other.containsKey(key2)) {
otherValue = other.get(key2);
if (value2 == null ? otherValue != null :
!value2.equals(otherValue)) {
return false;
}
}
case 1:
if (other.containsKey(key1)) {
otherValue = other.get(key1);
if (value1 == null ? otherValue != null :
!value1.equals(otherValue)) {
return false;
}
}
}
}
return true;
}

--
Stanislaw Osinski
http://www.carrot-search.com

15/May/05 6:24 PM

14 years, 46 weeks, 2 days ago

18869

No Perforce job exists for this issue.

0

34917

164579

0|i0sj5b:

Commons Collections

COLLECTIONS-15

[collection] ListOrderedSet doesn't implements SortedSet

Bug

Closed

Major

Won't Fix

Unassigned

Marc Guillemot

03/Jun/04 17:43

15/Mar/08 21:35

0

Operating System: other
Platform: Other

Is it a good reason why ListOrderedSet implements Set but not SortedSet?

04/Jun/04 4:28 AM

15 years, 43 weeks, 3 days ago

18983

No Perforce job exists for this issue.

0

29356

164693

0|i0sjun:

Commons Collections

COLLECTIONS-5

[collections] Map.debug/verbosePrint Thread Safety

Bug

Closed

Major

Fixed

Unassigned

Arun Thomas

11/Sep/03 10:26

15/Mar/08 21:35

0

Operating System: other
Platform: Other

This bug records a discussion on the mailing list, and provides a forum for
continuing that discussion. I include below the content of the mailing on the
list because they raise some interesting points.

-----------------------------------------------------
From: "Arun Thomas" <Arun.Thomas@solidusnetworks.com>
-----------------------------------------------------

I recently noticed that the current implementation of the debugPrint and
verbosePrint methods in MapUtils is not thread safe - in fact, these are the
only items that are not thread safe because the indentation state for the
output is preserved in a static variable.

I think it would be fairly simple to make this thread safe, but it would
require a change to the signature of a protected member function printIndent
(PrintStream out) -> printIndent(PrintStream out, int indentDepth). I'm not
really clear as to why this method is protected rather than private (can
anyone clarify?). Does it need to be protected?

Looking forward to input from others.
-AMT

------------------------------------------------------
From: Stephen Colebourne [scolebourne@btopenworld.com]
------------------------------------------------------

The methods that call this one are synchronized to protect them, so it
should be thread-safe.

However, I would prefer them not to need to be synchronized. If you want to
submit a patch that reworks the methods that would be great.

Incompatable change?
The protected method should remain and be deprecated, as it may be used by a
MapUtils subclass (feasible but unlikely). However, I would prefer just to
go incompatable change on this one. Other committers may differ, but if they
don't I'll just commit the incompatable change.

Stephen

---------------------------------------
From: Janek Bogucki [yan@studylink.com]
---------------------------------------

These methods are synchronized so are currently thread safe.

public static synchronized void verbosePrint (...)

public static synchronized void debugPrint (...)

I would guess that a second intentional benefit of the synchronization
is to prevent overlapping invocations writing to System.out at the same
time.

-Janek

------------------------------------------------------
From: Stephen Colebourne [scolebourne@btopenworld.com]
------------------------------------------------------

I like the System.out theory. Its probably unintentional, but it true. So
only a documentation patch is required then...:-)
Stephen

11/Sep/03 2:50 PM

16 years, 28 weeks, 3 days ago

18993

No Perforce job exists for this issue.

1

23092

164703

0|i0sjwv:

Commons Collections

COLLECTIONS-66

FastArrayList, FastHashMap and FastTreeMap not thread safe

Bug

Closed

Major

Fixed

Unassigned

Paul Jack

10/Apr/02 22:03

15/Mar/08 21:35

0

Operating System: All
Platform: All

Hi,

I noticed that version 2.0 of the Commons Collections
has been released so I thought I'd browse through the
code. While doing so I noticed something about
FastArrayList, FastHashMap and FastTreeMap.

List and Map objects can return views on their contents
that can be modified. For instance, elements can be
removed from an ArrayList via its iterator(). Elements
can be removed from a map via its keySet() or its values()
collection. A TreeMap can also return a submap that can
be modified. Generally, changes on a view of a collection
are reflected in the original and vice-versa.

The problem is, with FastArrayList or FastHashMap, in "fast"
mode, if somebody tries to modify a collection view (say, a
keySet() of a FastHashMap) they will never enter the FastHashMap's
monitor. The state of the FastHashMap can become corrupted if
more than one thread attempts to modify its keySet(); and threads
attempting a fast get(Object) on a FastHashMap while another
thread modifies its keySet() may get faulty data back.

Here's the list of methods that worry me:

FastArrayList.iterator()
FastArrayList.subList(int, int)

FastHashMap.keySet()
FastHashMap.entrySet()
FastHashMap.values()

FastTreeMap.keySet()
FastTreeMap.entrySet()
FastTreeMap.values()
FastTreeMap.subMap(Object, Object)
FastTreeMap.headMap(Object)
FastTreeMap.tailMap(Object)

17 years, 34 weeks ago

18932

No Perforce job exists for this issue.

0

7924

164642

0|i0sjjb:

Commons Collections

COLLECTIONS-74

[collections] Predicated Collections Throw IllegalStateException

Bug

Closed

Major

Fixed

Unassigned

Nick Heudecker

01/Apr/04 12:50

15/Mar/08 21:36

0

Operating System: other
Platform: Other

When calling ListUtils.predicatedList(List,Predicate), the underlying class used
to create the predicated collection throws an IllegalArgumentException when it
encounters an item that failed evaluation. This is not the documented behavior
for ListUtils, and it makes that method unusable.

It probably effects the other predicated collections available in the other
Utils classes.

02/Apr/04 4:13 AM

16 years, 4 days ago

18924

No Perforce job exists for this issue.

0

28115

164634

0|i0sjhj:

Commons Collections

COLLECTIONS-106

[collections] test failures for subclasses of AbstractBidiMapDecorator and friends

Bug

Closed

Major

Fixed

Unassigned

Michael Heuer

30/Dec/03 05:59

15/Mar/08 21:36

0

Operating System: All
Platform: All

The attached test case fails for a class that extends
AbstractOrderedBidiMapDecorator:

Testcase: testFirstKey took 0.04 sec
FAILED
expected:<foo> but was:<again>
junit.framework.AssertionFailedError: expected:<foo> but was:<again>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testFirstKey(AbstractTestOrderedBidiMap.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testFirstKeyTestcase: testLastKey took 0 sec
FAILED
expected:<all> but was:<you>
junit.framework.AssertionFailedError: expected:<all> but was:<you>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testLastKey(AbstractTestOrderedBidiMap.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testLastKeyTestcase: testNextKey took 0.05 sec
FAILED
expected:<we'll> but was:<gee>
junit.framework.AssertionFailedError: expected:<we'll> but was:<gee>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testNextKey(AbstractTestOrderedBidiMap.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testNextKeyTestcase: testPreviousKey took 0 sec
FAILED
expected:<gosh> but was:<again>
junit.framework.AssertionFailedError: expected:<gosh> but was:<again>
at
org.apache.commons.collections.bidimap.AbstractTestOrderedBidiMap.testPreviousKey(AbstractTestOrderedBidiMap.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testPreviousKeyTestcase: testBidiPut took 0 sec
Testcase: testBidiGetKey took 0 sec
Testcase: testBidiGetKeyInverse took 0 sec
Testcase: testBidiInverse took 0 sec
FAILED
Inverse of inverse is not equal to original. expected same:<{key1=value1,
key2=value2, key3=value3}> was not:<{key1=value1, key2=value2, key3=value3}>
junit.framework.AssertionFailedError: Inverse of inverse is not equal to
original. expected same:<{key1=value1, key2=value2, key3=value3}> was
not:<{key1=value1, key2=value2, key3=value3}>
at
org.apache.commons.collections.bidimap.AbstractTestBidiMap.testBidiInverse(AbstractTestBidiMap.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

The testBidiInverse test also fails for classes that extend
AbstractBidiMapDecorator and AbstractSortedBidiMapDecorator (not attached).

31/Dec/03 6:00 AM

16 years, 13 weeks, 6 days ago

18892

No Perforce job exists for this issue.

1

25811

164602

0|i0sjaf:

Commons Collections

COLLECTIONS-92

MultiHashMap.values() isn't backed by Map

Bug

Closed

Major

Fixed

Unassigned

Paul Jack

03/Jun/02 15:30

15/Mar/08 21:36

0

Operating System: All
Platform: All

The values() collection of MultiHashMap isn't backed by the map; changes to the
map are not reflected in a values() collection, and changes to the values()
collection are not reflected in the map.

Though MultiHashMap deliberately violates the Map contract in other ways, there
seems to be no legimate reason for it to violate the values() contract; since
values() can be implemented according to contract, it probably should be.

02/Nov/02 3:37 AM

17 years, 19 weeks, 1 day ago

18906

No Perforce job exists for this issue.

0

9573

164616

0|i0sjdj:

Commons Collections

COLLECTIONS-102

Bag interface violates Collection contract

Bug

Closed

Minor

Fixed

Unassigned

Paul Jack

29/May/02 02:49

15/Mar/08 21:36

14/Jul/06 12:05

1

0

Operating System: All
Platform: All

The following methods as defined by the Bag interface violate their
corresponding definitions in the Collection interface:

add(Object), addAll(Collection)
The Collection interface specifies that the add method should return true if
the collection changes as a result of the call. Since a bag's size always
increases as a result of an add operation, Bag.add should always return true.
The bag interface specifies that add(Object) will only return true if the
object was not already in the unique set.

remove(Object)
The Collection interface states that only one occurrence of a given object
should be removed as a result of this method. The Bag interface specifies that
all occurrences will be removed.

removeAll(Collection)
retainAll(Collection)
containsAll(Collection)
The Collection specification does not respect cardinality for these methods;
the Bag interface does.

The add, addAll and remove methods can be fixed easily, and code relying on the
old behavior can be rewritten simply using existing Bag methods:

boolean r = bag.add(obj)

can be replaced with:

boolean r = !bag.contains(obj);
bag.add(obj)

And

boolean r = bag.remove(obj)

can be replaced with

boolean r = bag.remove(obj, bag.getCount(obj));

The existing bulk operations could be implemented with static utility methods
in CollectionUtils (or possibly BagUtils), which would allow a smooth migration
path for code that relies on the current bulk operation behavior.

14/Jul/06 12:05 PM

13 years, 37 weeks, 4 days ago

18896

No Perforce job exists for this issue.

1

9467

164606

0|i0sjbb:

Commons Collections

COLLECTIONS-131

performing get(Object) operations inside of an iteration produces an infinite loop

Bug

Closed

Major

Fixed

Unassigned

Morgan Delagrange

09/May/02 01:03

15/Mar/08 21:36

0

Operating System: other
Platform: Other

I just "fixed" LRUMap, which was not promoting get(Object) operations correctly.
However, now if you perform a get(Object) within an iteration of the
keySet(), it will keep promoting values to the top and producing an
infinite loop. This needs to be fixed, by making the collection throw a
ConcurrentModificationException, or by fixing the behaviour in some other way.

10/Jun/02 6:16 AM

17 years, 43 weeks, 1 day ago

18867

No Perforce job exists for this issue.

0

8913

164577

0|i0sj4v:

Commons Collections

COLLECTIONS-76

FastArrayList, FastHashMap and FastTreeMap not cross-platform

Bug

Closed

Major

Won't Fix

Unassigned

Paul Jack

17/May/02 23:51

15/Mar/08 21:36

0

Operating System: other
Platform: Other

An optimizing compiler or a processor pipeline can reorder the operations that
clone the internal collection and reassign the reference to the clone. A
thread invoking a read operation can conceivably fetch a reference to a non-
fully-cloned collection, resulting in arbitrary behavior.

There seems to be no way to actually fix this bug, given the current Java
Memory Model. The code does seem to work on architectures that supply their
own more strict memory models, such as single-processor 386 systems.

At minimum, the documentation for these classes should be updated to indicate
that they are not cross-platform.

The Java Memory Model is currently under revision, and some future version of
Java will allow these classes to work by making the internal collection
reference volatile. (In the future, the volatile keyword will have better
semantics; a write to any volatile field by a thread will force a write of ALL
modifications made by that thread).

References:

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html

(These all deal with the double-checked locking algorithm, but the concepts
apply to these classes as well. Do a google search for "Bill Pugh" for more in-
depth information).

10/Aug/02 11:23 AM

17 years, 34 weeks, 3 days ago

18922

No Perforce job exists for this issue.

0

9206

164632

0|i0sjh3:

Commons Collections

COLLECTIONS-133

JavaDoc for ListUtils and FactoryUtils missing

Bug

Closed

Major

Incomplete

Unassigned

Colin

04/Oct/02 20:16

15/Mar/08 21:36

0

Operating System: other
Platform: Other

ListUtils and FactoryUtils are missing from the currently accessable commons
collection javadoc.
Maybe there are other classes missing?

25/Nov/02 4:35 AM

17 years, 19 weeks, 1 day ago

18865

No Perforce job exists for this issue.

0

13288

164575

0|i0sj4f:

Commons Collections

COLLECTIONS-83

Implementation of List with an AVLTree (TreeList)

Bug

Closed

Major

Duplicate

Unassigned

Joerg Schmuecker

05/Feb/04 18:33

15/Mar/08 21:36

0

Operating System: All
Platform: All

The existing Java List implementations are rather slow if it comes to big lists
and insertions and/or random access. To mitigate that this List is based on an
AVL-Tree and uses offsets to locate objects. The following benchmarks show the
performance compared to LinkedList and ArrayList.

add insert get
TreeList 300 501 110
ArrayList 70 20390 20
LinkedList 50 226636 279742

add - 100K times add( new Object() )
insert - 100k times add( random() * 100K, new Object() ) on a List with 100K
elements.
get - 100k times get( random() * 100k ) on a List with 200K elements.

P.S.: I will try to attach the code as a zip.

05/Feb/04 7:07 PM

16 years, 8 weeks, 5 days ago

18915

No Perforce job exists for this issue.

0

26679

164625

0|i0sjfj:

Commons Collections

COLLECTIONS-94

[collections] New feature: Extend ReferenceMap with IdentityMap functionality (WeakIdentityHashMap)

Bug

Closed

Major

Fixed

Unassigned

Andy Malakov

29/Jan/04 06:22

15/Mar/08 21:36

0

Operating System: All
Platform: All

Hello All,

I would like to ask your opinion on providing IdentityMap features to
ReferenceMap. (I am particularly interested in WeakIdentityHashMap)

Object cache is often implemented using ReferenceMap (WeakHashMap). This class
delegates decision on when to de-cache an objects on
Java GC.

In many systems Java objects that represent database instances use database
identity: methods Object.equals(Object) and
Object.hashCode() are redefined to use database identity (identity defined in
terms of object table + object primary keys).

When traditional java.util.Map is used to implement database caches different
instances of the same database objects present a problem: instances override
each other. Class java.util.IdentityHashMap (Apache Collections 3.0:
IdentityMap) can be used to solve this problem - this approach uses
System.identityHashCode() to obtain reference hashCode and Java comparison
operator to compare keys (and values).

What I need is functionality of IdentityMap combined with WeakReference-based
keys.

Is it possible to extend ReferenceMap with an ability to use reference identity
instead of object identity? I can send you my prototype if you are interested
(it adds about ten lines of code to ReferenceMap).

Here are some links to Sun's bug parade pages that describe similar feature
request for Java's java.util.WeakHashMap:

http://developer.java.sun.com/developer/bugParade/bugs/4809420.html
http://developer.java.sun.com/developer/bugParade/bugs/4500542.html

P.S. There is a need for this feature in Apache DB-OJB project.

All the Best,
Andy

16/Mar/04 8:24 AM

15 years, 48 weeks, 6 days ago

18904

No Perforce job exists for this issue.

2

26503

164614

0|i0sjd3:

Commons Collections

COLLECTIONS-109

Bug in CollectionUtils

Bug

Closed

Major

Fixed

Unassigned

Maarten Coene

24/Jun/02 15:12

15/Mar/08 21:36

0

Operating System: All
Platform: All

Hi,

there is a bug in CollectionUtils. If you pass in a Collection object which is
not an instance of List to the CollectionUtils.index() methods, the method
doesn't work: it just returns the given Collection instead of the i-th value in
the Collection.

I've already reported this (including a patch) to the commons-dev mailinglist,
but there was no reaction, that's why I'm trying it this way.

Here is the patch (if possible, I will also add an attachment including this
patch)

regards,
Maarten

cvs diff -u CollectionUtils.java
Index: CollectionUtils.java
===================================================================
RCS file: /home/cvspublic/jakarta-
commons/collections/src/java/org/apache/commons/collections/CollectionUtils.java
,v
retrieving revision 1.8
diff -u -r1.8 CollectionUtils.java
--- CollectionUtils.java 12 Jun 2002 03:59:15 -0000 1.8
+++ CollectionUtils.java 18 Jun 2002 12:23:34 -0000
@@ -500,6 +500,17 @@
}
}
}
+ else if(obj instanceof Collection) {
+ Iterator iterator = ((Collection)obj).iterator();
+ while(iterator.hasNext()) {
+ idx--;
+ if(idx == -1) {
+ return iterator.next();
+ } else {
+ iterator.next();
+ }
+ }
+ }
return obj;
}

10/Aug/02 7:38 AM

17 years, 34 weeks, 3 days ago

18889

No Perforce job exists for this issue.

1

10168

164599

0|i0sj9r:

Commons Collections

COLLECTIONS-10

[collections] minor javadoc fixes for OrderedIterator

Bug

Closed

Minor

Fixed

Unassigned

Michael Heuer

20/Jul/04 03:40

15/Mar/08 21:35

0

Operating System: other
Platform: Other

Minor javadoc fixes for org.apache.commons.collections.OrderedIterator.
diff -u attached.

23/Sep/04 6:19 AM

15 years, 27 weeks, 5 days ago

18988

No Perforce job exists for this issue.

1

30191

164698

0|i0sjvr:

Commons Collections

COLLECTIONS-108

[collections] [RFE] RemoveElementTransformer

Bug

Closed

Major

Won't Fix

Unassigned

Guillaume Coté

05/Aug/04 01:23

15/Mar/08 21:36

0

Operating System: All
Platform: All

There is transformer remove a element from a Set (modifing the original ser).
If I write proper javadoc and test case, could it be included in commons
collections.

17/Oct/04 6:01 AM

15 years, 24 weeks, 2 days ago

18890

No Perforce job exists for this issue.

2

30477

164600

0|i0sj9z:

Commons Collections

COLLECTIONS-63

[collections] compile failes with jdk 1.5 due to "enum"

Bug

Closed

Blocker

Cannot Reproduce

Unassigned

Georg Müller

06/Aug/04 05:21

02/May/13 02:28

15/Mar/08 21:35

0

LANG-124

Operating System: other
Platform: Other

enum is a keyword in jdk 1.5
so a lot off commons (not only collections) did not compile.
A lot of variables have the name enum.
Could this be changed, please.

23/Sep/04 5:23 AM

15 years, 27 weeks, 5 days ago

18935

No Perforce job exists for this issue.

0

30503

164645

0|i0sjjz:

Commons Collections

COLLECTIONS-79

[collections] [RFE] MapToArrayTransformer

Bug

Closed

Major

Won't Fix

Unassigned

Guillaume Coté

05/Aug/04 01:11

15/Mar/08 21:36

0

Operating System: other
Platform: Other

There is transformer received map and return a array containing the values of a
list of keys. If I write proper javadoc and test case, could it be included in
commons collections.

17/Oct/04 6:00 AM

15 years, 24 weeks, 2 days ago

18919

No Perforce job exists for this issue.

1

30474

164629

0|i0sjgf: